TL;DR:

Stick with SQL databases for now, and use whatever's easiest in whatever environment you're using. That's probably SQLite on your laptop, PostgreSQL if you're deploying to Heroku, and PostgreSQL or MySQL if you're deploying somewhere besides Heroku. And as soon as you deploy anything that has data that you care about, and will have multiple people using it, make sure to not be on SQLite.

More explanation below:

How much research should I be doing on my own?

Very little. If you're a complete newcomer to programming, you're going to have your hands full as it is. Your choice of database is not the first problem you have to solve.

SQL or NoSQL?

You may have heard of these new-fangled databases loosely called "NoSQL". They're cool, but they're a lot newer than SQL databases, which will cause you troubles when you're getting started. This isn't so much an issue of the technical merits of one style vs. another, but if you choose a NoSQL store that you're going to have an uphill climb with setup, installation, library support, documentation, etc.

SQL, on the other hand, is super-popular and might actually be older than you. That means that for every single SQL question you have, you're only a Google search away from an answer. Stick with SQL for now.

Which SQL database should I use?

There are three meaningful open-source SQL databases: SQLite, MySQL, and PostgreSQL. An over-simplified comparison might go like this:

• SQLite, as the name implies, is meant to be a very light implementation of SQL functionality. You can use it, say, if you're making a Mac application and need a good way to store structured data, but you don't want to go to the trouble of setting up a SQL server. This also makes it great for developing on your own machine, but since it's multi-connection functionality is limited, you're not going to be able to run an app on production with it.
• MySQL is a full-scale SQL server, and many large websites use it in production.
• PostgreSQL is also a full-scale SQL server, used by other large websites in production. This is actually my personal favorite, but that distinction doesn't matter when you're just getting started.

Any of these will get you what you need: A place to store your Rails data and a way to start learning SQL bit-by-bit. You should optimize for ease of installation or deployment. So that means:

• SQLite when you're working on your laptop
• PostgreSQL if you're deploying to Heroku, since Heroku favors PostgreSQL over MySQL
• PostgreSQL or MySQL if you're deploying somewhere else. Check their docs and use whatever they tell you to use.

And it's going to be fine, at first, to have the same app using different SQL engines in different environments. At some point you may end up using some really specific, optimized SQL that SQLite can't run, but that's not a newbie problem.

So I switched to Vim, and now I love it.

For years, I was actually using jEdit, of all things, even in the face of continued mockery by other programmers. My reasoning was well-practiced: TextMate didn't support split-pane, all the multi-key control sequences in Emacs had helped give me RSI, and Vim was just too hard to learn. jEdit isn't very good at anything, but it's okay at lots of things, and for years it was fine.

But eventually, I took on a consulting gig where I was forced to learn Vim. And, as so many have promised, once I got over the immensely difficult beginning of the learning curve, I was hooked.

Continue reading “Vim” »

Over time, technological progress makes it easier to write automated tests for familiar forms of technology.

Meanwhile, economic progress forces you to spend more time working with unfamiliar forms of technology.

Thus, the amount of hassle that automated testing causes you is constant.

Looks like your Twitter bots need to be better at quote-escaping:

My Goruco 2012 talk, "The Front-End Future", is now up. In it, I talk about thick-client development from a fairly macro point-of-view: Significant long-term benefits and drawbacks, the gains in fully embracing REST, etc.

I also talk a fair amount about the cultural issues facing Ruby and Rails programmers who may be spending more and more of their time in Javascript-land going forward. Programmers are people too: They have their own anxieties, desires, and values. Any look at this shift in web engineering has to treat programmers as people, not just as resources.

Francis Hwang - The Front-End Future from Gotham Ruby Conference on Vimeo.

As always, comments are welcome.

This isn't just the event New York Rubyists want. It's the event they deserve.

Thanks so much to all the co-organizers for pulling this off. Everybody else: See you next year, if not sooner.

And there's this, too: Ellipsifier is a Javascript library that truncates HTML. It will retain the tag structure, counting only visible characters in the resulting text.

new Ellipsifier("to be or not to be", 5).result
//              "to be …"
new Ellipsifier('to <strong>be or</strong> not to be', 20).result
//              "to <strong>be or</strong> not to be"
new Ellipsifier('to <strong>be or</strong> not to be', 5).result
//              "to <strong>be</strong>&nbsp;&hellip;"

Another chunk of code written with the good folks at HowAboutWe.

The folks at HowAboutWe do a decent amount of HTML email, as you might expect for any site where people can send each other messages. Dissatisified with the tools for developing HTML email, I wrote EasyMailPreview, a Ruby gem that makes it very easy to see the results of an HTML email in development mode. It auto-discovers mail methods and method arguments, and lets you write them on the fly with in an admin-ish screen.

I've been using it for a while, and I find it eases the pain of developing HTML emails. Somewhat.

I wrote a little something about Goruco on the Goruco site:

Let me make a confession: Before we hosted the first GORUCO, I kind of didn’t want to be bothered. NYC.rb had been a successful Meetup for years, and people would occasionally say “you know, we could have a great regional conference here.” Which made sense in theory, but just thinking about the work involved gave me a headache. I usually smiled politely and tried to change the subject.

It's worth a read if you're not already convinced this year will be the best Goruco evar. And if you have yet to buy your ticket.

So, I'm speaking at Goruco this year. On The Front-End Future:

With the rise of Javascript MVC frameworks like Ember and Backbone, web programmers find themselves at a fork in the road. If they keep doing server-side web programming, they'll benefit from tried-and-true tools and techniques. If they jump into Javascript MVC, they may be able to offer a more responsive web experience, but at significant added development cost. Which should they choose?

This talk will address the strategic costs and benefits of using Javascript MVC today. I will touch on subjects such as development speed, usability, conceptual similarities with desktop and mobile applications, the decoupling of rendering and routing from server logic, and the state of the emerging Javascript MVC community. I will also discuss the impact of this seismic change on Ruby, Rails, and your career as a software engineer.

Nobody should confuse me with a Javascript expert, and that's not why I'm giving this talk. There are many talks you can see that focus on the specifics of implementation that are being hashed out today. With my talk, I will be drawing out the macro trends in our field that affect the products we build, and the careers we craft.

In particular, I feel like the move to thick-client web apps is giving the Ruby and Rails community a bit of existential paralysis--we should be talking about this far more, and meeting this change head-on. The future is uncertain, but it is also bright.

Goruco is on Saturday, June 23. This is our sixth year, and without giving away the rest of the speakers, I think this might quite possibly be our best program yet. If you want to join us, tickets are still available.