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.
> It is awkward because Javascript is asynchronous and you want to make sure the user interaction stays responsive without devolving into spaghetti.
This is exactly the feeling I've been getting recently as I foray into writing my first Chrome extension. The asynchronous nature of XHR is ending up making my code a little more spaghetti-like that I would prefer. Would you happen to have any recommended resources for possible approaches to addressing this issue?
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.
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).
I wish more people knew about FreshBooks' rewrite. They had horrible code. And they slowly morphed it into a php-python-ruby mix which is (from my dev friends there) pretty damn good now. It's ok to have a setup or tools that are fucked, but FB would never be able to hold onto developers or iterate quickly on their product if they hadn't sunk at least 9 man-years on the clean up. A million bucks for a slow rewrite is worth the price when it mitigates the risks of a failed from scratch rewrite.
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.
Ah, but in Go there is the concept of good shape - you can play along similar strategic lines with both good and bad shape, but if you play your stones clumsily (write your code in PHP?), you will be vulnerable to many forcing plays and clever tesuji that may transform the position into an unwinnable one. It could happen during the middle game - bad shape may allow a group to be cut in half or have its eye shape pounded out of it - or in the yose, where you may need to make a very large number of moves to defend very few points (long development cycles to add features to a poorly written product?).
Therefore the analogy of Go justifies spending time making good shape with your code as you go along.
The problems are very challenging, but that shouldn't stop you from thinking about them and then enjoying the enlightenment of the answers after a minute. Very helpful material! Best of luck in your pursuit of a better game
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.
For someone who's known of Go but never took the time to learn or play it, that's the best sales pitch for it I've ever heard. Makes it sound like it has the fundamental simplicity of checkers and the strategic complexity of chess. Adding it to my learning list now.
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?
I'm suspicious that I won't find it useful. Pencils and paper are awfully nice. I bet that even a trained user of this software can't write an equation faster than I can.
Sometimes it is nice to be able to typeset equations, or feed them into Matlab or Mathematica, and I guess this might help with that. But I don't own Matlab or Mathematica anymore.
And, yes, the paper requires you to know that m is a mass with units of kilograms and q is a charge with units of coulombs, and that the m in one equation is the same as the m in another. But if you can't keep track of that yourself I'm not sure why you're bothering to write down equations.
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.
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.
Absolutely. I love Vagrant. Last night one of my virtual machines flaked out, and because everything was managed with Puppet, I just deleted the VM and told vagrant to recreate.
10 minutes later I was back in business like nothing happened.
Had a physical machine of mine failed it would have been a fun few hours of machine debugging, instead of "oh, I'll just destroy and recreate the VM, no biggy"
Interesting - I see we both have projects on github called "vagrant-base"!
On mine (https://github.com/drench/vagrant-base) each branch sets up a different environment (Drupal, node.js, generic "LAMP", etc.). They currently all use shell scripts for initialization, but converting them to Puppet is on the list. I may borrow from your project's Puppet manifest.
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.
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:
The general doctrine sounds great. The specific solution outlined sucks. My hypothesis: easier to get in touch with primal survival instincts and twiddling that directly. The author is still answering those self-reflection questions with abstract thoughts that has nothing to do with survival instincts.
Meaning: Interrupt yourself every time you feel procrastination -- that heavy, draining, depressing, oppressing feeling -- that sudden drop in energy when thinking about taking the next step -- or even planning and deciding the course of action to take you to your goal. Catch yourself feeling this. Then directly manipulate that.
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.