March 31st, 2008 — 7:00pm
In getting Potion Store integrated with my site, I had to learn Ruby on Rails. RoR has always been one of those things I’ve been curious about so I saw it as an opportunity to dive in. I present here a first impression. Note that these are impressions. They represent how I perceived things coming to it for the first time. While chances are that these perceptions are inaccurate, there’s something to be said for seeing how things appear to fresh eyes.
Ruby is an interesting language. It appears to be very flexible and dynamic, allowing you to do a bunch of really neat things that you can’t in most other languages. Note that these features aren’t really unique to Ruby. My sense is that Ruby is not a distinctive language in itself so much as a mostly good mix of other languages. I say “mostly” because I’m not sold on the syntax. It reminds me too much of Perl. It’s like they created a great new flavor of ice cream and then mixed in glass and razor blades.
My advice to those picking up Rails for the first time, get the Rails book and read the first few chapters before diving in. I found the online tutorials kinda annoying and not as good at explaining the structure and conventions that Rails relies on. Rails’ strongpoint is streamlining common tasks and functionality but to do so, it expects things to be laid out in a certain way. The other thing that takes time to figure out is the “magic” that Rails performs at certain points. One of the great things about Rails is how certain things are automatic. Very little glue needs to be coded and I feel that’s a wonderful thing. On the downside, sometimes this magic makes it hard to figure out what’s going on. For instance, some classes had naming patterns for their methods that you had to find out about in the documentation. I found the quality of the documentation to be a bit uneven which didn’t help in some cases.
I feel most of the problems with Rails are less about the design and more about the implementation. For instance, Rails is a memory hog. And because Rails is single-threaded, you need to have at least two of these things sitting there to get any sort of concurrency. When I deployed my store, I had to upgrade my SliceHost slice as the 256M slice wasn’t cutting it (remember I’m also running mysql and PHP stuff). Also, I felt deployment was a bit clumsy, as I had to set up a cluster of mongrel instances to run my app with apache acting as a proxy. While I see that there is a mod_ruby for apache out there, no one I know recommended it. Nonetheless, I felt like I had to deal with more moving parts than was necessary.
In a nutshell, Rails: great, Ruby: enh. If you are going to buy a book on it, get the Rails book first. It has an appendix on Ruby that should be sufficient for most things. If you want to go deeper with the Ruby side of things, you can get the Ruby book as well but personally, I could have done without it.
Overall, I like the platform but at the same time, I can see that it’s relatively immature and has some ways to go. I’m pretty much tied to RoR for now since it’s what the store is written in but that’s not a bad thing. That said, I also am not so amazed that I am going to join the Ruby cult.
Nonetheless, RoR feels like how a web framework should and less like a bloated platform where you end up installing a hundred frameworks requiring just as many config files to be edited to solve non-existent problems that are justified because someone gave it a fancy technical name along with a contrived design pattern to fix it (if you need a hint as to what I’m referring to: “starts with a J”). RoR seems to be able to identify and address the actual problems people run into when creating web applications, all the while keeping it relatively simple, and that is refreshing to see.
6 comments » | Programming, Ruby on Rails, Web
March 20th, 2008 — 4:47pm
In my recent quest to deal with some long needed “home improvement,” I’ve just rolled out my own store based on PotionStore. For those that don’t know, PotionStore is an open-source store implementation done by Andy Kim. It’s used by PotionFactory, of course, as well as a few other shops.
Until now, I’ve been using Kagi for all my payment processing. Kagi is great for someone starting out as they provide the store, deal with taxes and can even provide a license number generator. I think when you are doing your first release, outsourcing the commerce side to someone else can save a good deal of time.
So why am I switching off Kagi? Mainly much lower commissions on each transaction and more control over the store itself. I was finding that the commissions were adding up to significant money as my volume rose and there were certain features I wanted to add that I couldn’t. On top of that, there was a bit of confusion regarding having customers dealing with a 3rd party.
Unfortunately, now with my own store, I am going to have to charge sales tax to New York residents. One of the downsides to living in the same state as me. Trust me, I’m not looking forward to doing the tedious sales tax filings.
The result of all this is a store which I hope looks nicer and has a more streamlined flow. I’ve added the ability to download your licenses immediately as well. You’ll still get them emailed to you but this way, you’ll get instant satisfaction coupled with some level of redundancy.
So, give it a spin. Maybe even buy something . If anything goes wrong, or even if everything goes right, I’d love to hear about it.
2 comments » | Noodlesoft, Web
March 10th, 2008 — 9:51am
Recently, Quentin Carnicelli of Rogue Amoeba asked if there were NSResponder methods that you could hook your “OK” and “Cancel” buttons to to dismiss a modal panel (or sheet). As far as I knew there wasn’t but, gosh darnit, that would be a useful thing to have.
To clarify what I’m talking about here, when you run your own modal window or sheet with “OK” and “Cancel” buttons (or some equivalents), you end up hooking those up to methods that dismiss the window/sheet, stop the modal session and return some code (either one for confirmation or cancellation). Most of the time, you end up writing the exact same code. It’s glue code that shouldn’t have to be written.
Now, if you look at NSResponder, you’ll see all sorts of action methods in place. Sticking these glue methods into NSResponder will allow you to hook up your “OK” and “Cancel” buttons to the “First Responder” in IB. The idea here is that there is a default implementation that will close the current modal window or sheet and set the return code to either
NSCancelButton. With this, your code can act more like it’s using
NSBeginAlertSheet() by just interpreting the return code.
I’ve created an NSResponder category with the methods
-cancelModal: to which you can hook up your “OK” and “Cancel” buttons in IB. Note that you may have to manually add the methods to NSResponder in IB as it doesn’t know about them.
Now NSResponder’s versions of these methods don’t actually do anything besides pass it on to the next responder. The main part is in NSWindow, which overrides it. It will check to see if it’s the current modal window or sheet, order itself out, stop the modal session and send back the appropriate code. By using the responder chain, this mechanism will find the “nearest” modal window. Note that it is assumed here that the buttons to dismiss a modal window are in the same window. If you want to dismiss it from a different window, it may or may not work (depending on the responder chain and other subtleties such as the odd specification of NSWindow’s
-isSheet method). I can’t think of a non-contrived case where you’d want this or care but if one comes up, let me know.
So here’s the download. Suggestions, questions, bug reports appreciated.
2 comments » | Cocoa, Downloads, OS X, Programming
March 4th, 2008 — 8:48pm
If you are reading this right now, then that should mean that the host migration was successful. No, I didn’t accidentally re-post my last article. I’ve moved Noodlesoft to yet another hosting provider. Noodlesoft is now on SliceHost.
Unfortunately, things didn’t work out with WebFaction so I decided to go shopping again.
While many people were recommending SliceHost, I resisted as I wasn’t relishing the idea of doing sysadmin work. I’ve done my fair share in my lifetime, including compiling kernels, setting up firewall rules and mucking with sendmail.cf files. The whole purpose of using shared hosting was that I could pay someone else to do it. Nonetheless, I found myself in need of a higher level of reliability and control. I had to bite the bullet.
I signed up and within minutes, was logged in to my slice. And oddly enough, I found myself actually enjoying setting up my server. Sure, it took some time to get everything up and running but not as long as I expected. It’s put together the way I want and if something goes wrong, it’s hard to beat the response time of going in and fixing it myself. It’s not for everybody but if you know what you are doing then I say give it a try. I would recommend paying extra for the backup feature where you can save snapshots (or have snapshots automatically taken daily or weekly). Restoring slices from these snapshots is quite easy in case you mess up or something else goes wrong. They also have articles on how to install most of the software you’ll need to get up and running. My only beef right now is that I’d like more snapshots slots available (you only get 3).
Here is the obligatory/shameless SliceHost referral link in case you are interested in signing up.
Oh, and I am keeping my DreamHost account for things such as hosting my mail. Also, since DH’s plans offer ridiculous bandwidth, it’ll be good to have as a backup when there’s some sort of burst.
And because it’s what I’ve been dealing with for the past couple weeks, you’ll probably see some sysadmin articles from me in the near future. I’ve even added a “System Administration” category. I’ll post a report on SliceHost and my experiences with VPS hosting in a month or two.
5 comments » | Noodlesoft, System Administration