Mel’s job was to re-write the blackjack program for the RPC-4000. (Port? What does that mean?) The new computer had a one-plus-one addressing scheme, in which each machine instruction, in addition to the operation code and the address of the needed operand, had a second address that indicated where, on the revolving drum, the next instruction was located. In modern parlance, every single instruction was followed by a GO TO! Put *that* in Pascal’s pipe and smoke it.
Mel loved the RPC-4000 because he could optimize his code: that is, locate instructions on the drum so that just as one finished its job, the next would be just arriving at the “read head” and available for immediate execution. There was a program to do that job, an “optimizing assembler”, but Mel refused to use it.
“You never know where it’s going to put things”, he explained, “so you’d have to use separate constants”.
Nothing insightful to say here but just link to the blow-by-blow account of the incident as it happened
Apparently it was such a big deal that even Justin Timberlake weighed in … pure hilarity. The ironic thing is one of the folks I work for, *just* got a rackspace server.
I was working on a rails app today, and got to wondering about the very many
SHOW FIELDS FROM
MySql queries I was seeing.
I had always thought about whether there was a way to get rid of those completely, or reducing the number of them by caching or something.
Well, today I actually did some digging and found this little gold nugget about “SHOW FIELDS” calls in Rails.
Apparently, Rails does cache MySql “SHOW FIELDS ” with one notable exception.
However, upon inspection it turns out that Rails DOES NOT cache ‘SHOW FIELDS’ queries for has_and_belongs_to_many associations. So every time a select or an insert is done via a Rails has_and_belongs_to_many association, a ‘SHOW FIELDS’ on the join table is executed.
So the dreaded HABTM association strikes again!
Those darned things are pure evil eh?
Well the awesome blog writer figured out a patch to fix the problem.
And in his tests he reported this (see image below for reference) …
After rolling this change out we have seen a very noticeable improvement on performance. By using New Relic’s Compare With Yesterday feature (see chart below) we can see that our application response time dropped from an average of about 560 ms per request to 420 ms per request. This is roughly a 25% performance increase. The yellow line shows today, the blue line is yesterday. CPU and database load decreased by about 25% as well.
A 25% improvement in application response time!?!?!
Sign. me. up.
I followed the Rails ticket on this particular issue and couldn’t figure out whether the fix had been rolled into a Rails version yet. I asked the blog author and he says the patch has been included in Rails 2.3, so if you’re running that, this does not apply to you.
I’m about to apply this patch to a couple of applications, hopefully it helps you too.
Please post in the comments about your experience. Same? better? worse?
This one has eluded me for quite some time, until I came across the answer here
Simply hit alt+fn+F11 to do a screen capture on a Macbook Pro (fn+F11 maps to Prt scrn on a mac running bootcamp)
updated: If you have a newer version of bootcamp (2.1+) the combination is now shift+alt+fn+F11
Why doesn’t someone make a laptop with dual video cards on it?
That way you can run two displays in addition to your laptop instead of one.
It wouldn’t have to be able to run a 2560 x 1600 display on both cards, 1920 x 1080 will do (that’s two nice 24″ displays). I know lots of developers who’d pay good money for that.
PS: As with all ideas posted on this blog, feel free to take them and use as your own.
Whether you’re successful or not, it’d be awesome if you’d write back and let me know
While my initial user experience was dandy, I have since discovered some show stopping bugs.
- When trying to import your plugins from a previous version (6.5 in my case), the screen that pop up mysteriously disables mouse clicks.
So you basically get stuck at a screen like this one …
… with no possible way of moving forward or back.
I had to kill the netbeans process and restart (happened in both rc2 and rc3).
To be fair, after restarting, I had no more problems … the plugins seemed to have imported just fine.
- I also discovered another odd problem while trying to work on migration files in Rails. After Netbeans produced one intellisense dropdown, the entire IDE would start freezing on every 2 or three key strokes … making itself unusable. I had this problem in rc2, no such problem with rc3.
- On the plus side, startup time is *a lot* faster than in 6.5. As soon as I loaded a few modules the startup speed went back to be cell-phone-customer-service slow, so no plus there.
+ The whole netbeans process seems to be self contained now. It used to be that when you looked in process explorer, you’d see Netbeans, nbexec and java, with the real size of netbeans contained in the Java process.
This, happily, is no longer the case. Netbeans still easily tops 200MB of memory though :\
- Trying to create a new rails app, the browse button on this screen does not work, terrible eh?
PS: This worked for Netbeans 6.7 RC2, however it will HORRIBLY break any attempt to use irb from the windows command line
If you right click on a project in Netbeans then go to ‘Ruby Shell (IRB)’, you should get dropped into a ruby IRB window.
Unfortunately for most of you on windows, you might get this instead …
An easy fix is to go to irb.bat and comment out the first 7 lines of code so that it looks like this
#@echo off #@if not "%~d0" == "~d0" goto WinNT #\bin\ruby -x "/bin/irb.bat" %1 %2 %3 %4 %5 %6 %7 %8 %9 #@goto endofruby #:WinNT #"%~dp0ruby" -x "%~f0" %* #@goto endofruby #!/bin/ruby # # irb.rb - intaractive ruby # $Release Version: 0.9.5 $ # $Revision: 11708 $ # $Date: 2007-02-13 08:01:19 +0900 (Tue, 13 Feb 2007) $ # by Keiju ISHITSUKA(email@example.com) # require "irb" if __FILE__ == $0 IRB.start(__FILE__) else # check -e option if /^-e$/ =~ $0 IRB.start(__FILE__) else IRB.setup(__FILE__) end end __END__ :endofruby
I’d been using 6.5 for the last couple of months, forgetting to look for updates in my RSS feed, when I came across the announcement of Netbeans 6.7 RC 2.
I quickly downloaded it and started using it, when I found out that RC3 was released just yesterday as well, I’ve downloaded it, but since I’m in the middle of a slew of projects I won’t be installing it until the weekend.
However with RC2, I am impressed that they finally fixed the silly problem of each version of Netbeans not importing settings from previous versions.
The install went smoothly and I was up and running faster than usual.
The things that jumped out at me are
+ There is no annoying subversion connection window that jumps up in the output section for each project that you’re working on any more
- The Ruby irb output window still doesn’t work for me (see screenshot)
- Still no word wrap (I know they’ve said to expect it in version 7.0, but seriously …)
- I spent almost 2 hours yesterday trying to figure out what changed between RC3 and RC2, and I couldn’t do it.
If you can, please drop me a line.
Apparently with each new release, the documentation page updates to the current release. So basically there isn’t a release page for RC2 any longer (please fix this guys).
+ For Ruby on Rails here are the things that are new (nothing exciting really)
Here are the release notes for RC3
Ruby and Rails
- Remote debugging support
- Improvements to Ruby constants support
- Run and debug actions for test cases and suites included in context menu
- Support for Shoulda tests