Someone on the comments for the original article said, the big idea in Rails wasn't so much MVC as much as separation of concerns. I'm on-board with that. Thinking in that way has brought a lot of advantages for me over the years I've been working with Rails.
By extension, if the big idea is "separation of concerns", then I should be applying it in my non-Rails code too, whether that's "MVC" or not "MVC". In fact, my small taste of functional programming allowed me to play with "separation of concerns" in a different coding style, one that I've imported back into the Ruby code I write. Write functions without side-effects. Treat data as immutable. Interesting times.
Agreed. I can't find any insight or advantage in making this kind of a distinction.
The article attempts to address it by saying that people attempt to implement Model2 on a Javascript front-end. That is awkward. However, it isn't awkward because you should be using real MVC. It is awkward because Javascript is asynchronous and you want to make sure the user interaction stays responsive without devolving into spaghetti. The key insight is "asynchronous" rather than "let's do REAL MVC!"
I've seen this obsessive focus on taxonomy of solutions divorced from specific problems in domains outside computing. I suspect it's a cultural thing. Some cultures obsess over gadgets more than others. That works out until people start arguing about who has the shinier toy, instead of actually using said toys as tools.
I'm observing some people trying to break into technology. Yes, there are online tools available. Yes, many of them are free. One of the complaints I hear is that the target platform you choose moves so fast.
Generalized, it means software -- the technology and the economy -- runs at a higher tempo. In order to step into the stream, you have to first match the new tempo.
I suspect that the rest of the economy stays in a slump because they are out-of-phase tempo-wise with software technology ... or that the tools that drive up the tempo of innovation in software has not made it out to the mainstream yet. (And even if it did, it will leave people behind simply because there are people who will refuse to impedance match).
Funny you should mention that. Right after you talked about shapes, I browsed through Sensei's Library and saw that too. Thanks for the recommendation.
Unlike chess, stones don't move once played. They can only be captured. On a 19x19 board, you have to balance short-term gains with long-term gains. Since there are no left-right or top-bottom orientations, you often have to reimagine where you draw the lines of territory as you play. Sometimes, you can kill your shapes by playing too many stones. Better players can see where things will go, identify "dead shapes," and stop wasting time trying to rescue them. Sometimes you trade off bad moves for bigger gains. Sometimes you simply have to work with mistakes you made in the early game.
This is very much like writing code and getting it to market. You're trying to build something despite disruptive opposition even as the clock winds down.
I don't remember. I'm not very good at writing posts that get a lot of upvotes. You are more then welcomed to try -- this app can get all the marketing help it gets.
Want to see a non-incremental innovation for multi-touch calculators?
A friend of a friend wrote this: http://mathtouchapp.com/ (He doesn't know I'm linking it here).
The app throws away the calculator metaphor and starts from scratch. Instead, the author uses the back-of-a-napkin as the metaphor.
You start with a blank page and add systems of equations. You can visually link variables together. You can insert values along with its unit of measurement and numeric precision. You can feed results to graphs.
At $10, this is cheaper than getting the Nspire if you already have an iOS device. But of course, you can't use it when taking the SAT. And it would be cool if you can export it to Wolfram's computational data format and trade formula libraries.
You need to actually understand the math instead of just punching the buttons. Then again, isn't that what Sal Khan's videos are for?
Gentoo can be a pain in the ass, but the occasions when I need package masking and using precise, specific library versions, there's nothing else that does it.
Ultimately, I think Homebrew will win out because:
Some context. I started this current gig 18 months ago. I develop on Ruby on Rails (of course), and ultimately deploy it into the Rackspace Cloud. I also wanted to mess around with Opscode Chef. I had also watched friends and business partners struggle with MacPort for years, and watched them struggle with bundler and rvm more recently. I wanted to skip that.
I'm actually using VMWare Fusion. My employer had an extra copy. I run VirtualBox at home. The platforms are not exactly the same, but my beefier gaming box running (now older version) of VirtualBox seem slower. For the purpose of developing in a VM, I don't think it really matters between VirtualBox or VMWare technology-wise, as long as you have some sort of command-line tool to bring up new VMs.
I wrote some bash scripts to clone VMWare images, including filters to search name references and rename them to the image. You can use Vagrant to do the same with VirtualBox, and from the demos I've seen, it is a easy way to get into this setup on your MBP.
I built out a template with 256M + 10 GB slices, just like on Rackspace Cloud. On the i5 MBP, I allocated a single core to each slice. On my current i7/8GB setup, I'm allocating two cores. I've also had to beef up two of the slices from 256M to 512M and 1G so that I could run the full rspec against the apps. I have tried allocating all 8 hyperthreaded cores, but I guess VMWare Fusion isn't quite like Xen. I generally run no more than two slices at a time. VMWare Fusion makes it relatively easy to suspend VMs, and I don't jump around on a number of projects so I have not needed to hot-potato things much.
I had not had problems with VMWare with regards to idling. Both VMWare Fusion and VirtualBox are now using Xen-style paravirtualization, so when it is idle, it sits idle. When it does eat up computing cycles when idle, it has more to do with Rails (or Merb) polling inappropriately. With this setup, I've had problems on the i7 MBP kicking up the fan for no apparent reason and I suspect it is Chrome or Flash.
Wakeup/suspend by closing the lid works on the VMs. Linux doesn't even know the VMs have been suspended, so I don't mess with any kernel settings for that. On the downside, these VMs currently run on an independent wall clock which means resetting the clock if I want accurate timestamps on commit logs. There's probably a setting to fix that.
I'm using Gentoo for the distro, but that doesn't matter as much as using the distro you like or better yet, using the distro you are deploying against.
Editor-wise, I am shelling in with ssh and using vim + Rails.vim against screen. (I'm also using Terminal.app + Visor and iterm2 w/ visor mode). I have a customized /etc/hosts file with shortnames for the VMs so I can shell in fast on the occasions I do shell in. (I have flirted with shelling in and using Emacs -- it works wonderfully well, if I wanted to abandon VI modal editing).
Each slice is configured with two virtual ethernet devices, one going to physical ethernet device (bridged) and one going to the virtual LAN (no NAT). Since I sometimes go use free wifi and they require IP authentication, I don't see the point of exposing the internal slices to the world. Instead, I installed Nylon through MacPorts and have it turned on to accept SOCKS5 requests from anything inside the virtual LAN. On the VM side, I have proxychains set to talk to Nylon on the outside. This way, I only have to web-authenticate once on the free wifi and prepend my git pushes with proxychain. With the virtual LAN, the intent was so I can always shell into my vm on my laptop regardless of my external network connectivity.
One nice thing about this setup: at some point, when the Gems start accumulating and start bogging down load time for Ruby and Rails, I can drop it and clone a new VM.
Due to some circumstances, I'm going to be getting an i7 Air by the end of this month and I'll replicate the setup. I may use Homebrew or Gentoo Prefix on the host side, but I'll still continue to use some sort of virtualization of Linux. I'm skeptical about drinking the 'brew ...
I have a friend with a similar setup. The friend has to run Windows to do proper browser testing so he has different requirements. He also has FUSE running with a Samba shared folder so he can use TextMate on the host side and run things on the Linux side. I've only had a few occasions where I wished I could do that, virtual DropBox-style, but it hasn't reached the level of scratching-itch yet.
I run Linux ... virtualized in OSX. Because OSX and MacBooks has wireless that just works. It has networking that just works. And it has suspend/wakeup that just works. But its bundled UNIX toolchain sucks, and Macports, et. al. don't just work.
I run the VM headless, sized similarly to a typical Rackspace Cloud server. This setup lets me use the GNU toolchain while being highly mobile.
Someone on the comments for the original article said, the big idea in Rails wasn't so much MVC as much as separation of concerns. I'm on-board with that. Thinking in that way has brought a lot of advantages for me over the years I've been working with Rails.
By extension, if the big idea is "separation of concerns", then I should be applying it in my non-Rails code too, whether that's "MVC" or not "MVC". In fact, my small taste of functional programming allowed me to play with "separation of concerns" in a different coding style, one that I've imported back into the Ruby code I write. Write functions without side-effects. Treat data as immutable. Interesting times.