I briefly looked at Ruby a while ago, when it started getting attention because of Rails and all that. This week I decided to take a closer look at it, and skimmed through some tutorials. Ruby seems nice, but there are some things that make me wonder wtf is going on…

So, you’ve built your nice little web application, and all is well. Users are using it and filling your nice little database with data. Then suddenly, things start disappearing. Everything that the users have spent hours creating is deleted, one row at a time. What’s happening? You start debugging… Someone is actually clicking the links to delete content. Sabotage, perhaps?  You search through the logs and find the IP address of the offending user. After tracing the activity of that user, you track it down to Bob, one of the web developers.

(Here’s a re-post from my other blog.)No, I’m not going to say the obvious: use placeholders or positional arguments to avoid SQL injection. All developers should know that. Except that it’s not entirely true. Yes, you read it right. Let me explain…Placeholders are most commonly used in conjunction with prepared SQL statements, and the primary purpose of this is not to avoid SQL injection, but to make applications more efficient.

Repeat after me: never trust input in web applications. Never ever. Don’t trust input in GET requests. Don’t trust input in POST requests. Just don’t do it.

“Oh, but that’s ok,” you think, “I always check data that the user inputs.” But no, that’s not enough! Any data that is recieved by the web application has to be checked before you use it…

That, or … Kill everyone that attempts XSS attacks. Why can’t people just use the #@!±?% web applications as they were intended to be used?!

sigh

Update: this goes for HTTP headers as well, btw. Don’t trust them!  It’s not difficult to forge them.

There’s an amazing Emacs module called Tramp. It enables you to do remote editing… For instance, you can simply do Ctrl-x Ctrl-f //ftp:user:password@ftp.example.com:/foo/bar to edit files on an ftp server. Tramp handles moving the files it as transparently as possible.

What’s even more ingenious, is that you can do this “multi-hop”, i.e. you can edit files on a remote server by going via another server. For instance, I have an account with an ssh key that is authorized to log into other servers, but I don’t want to have that key on my own computer. To edit files on one of the other servers, I can do Ctrl-x Ctr-f //multi:ssh:vetler@server1:ssh:vetler@server2:/path/to/file to edit files by going through server1.

Amazingly clever, and I couldn’t live without it.

Jesper posted something about remote editing in OS X today, which inspired this post.

I’ve been playing around with Android lately, and since it comes with a very nice Eclipse plugin, I’ve been using Eclipse again. For the last 4 years, Emacs has been my only IDE, but before that I used Eclipse quite a lot. I was doing J2EE development back then, and Eclipse was a life saver.

Using the Android plug-in (ADT) got me thinking about a problem with these plug-ins … They can make things too easy. To build Android apps, you need some kind of logic. If you create a project with the Android SDK command line tool, activityCreator.py, then you get an Ant build file. With the ADT, you get no such thing because it does  it automatically.

“Great!” you might think. But no… The problem with this is that you make Eclipse a dependency. If you want to share your code with others, you’ll have to commit the Eclipse-specific files to make sure it’s recognized as an Android project in other Eclipse installations and everything is generated properly. The problem with this, of course, is that everyone has to use Eclipse… That might make it a little hard to do automated building, testing and such things.

The solution might be to  generate  an Ant build file, and add it to the project. That will work, except you’ll have problems running the Ant file in Eclipse, since there’s an auto-generated file that is set to be read only by the ADT. In this case the ADT is really just trying to be helpful, but the road to hell is paved with good intentions. sigh

Nothing wrong with IDE plug-ins that help out, but any plug-in that has magic such as this, is flawed. There are many things IDE plug-ins can do to help, but making projects IDE and IDE plug-in dependent is not something they should do.

So, you’ve installed the Eclipse Android plugin, and are hacking happily away on the next revolutionary app that will  make you win the contest and  more… But for some reason all you get when running your Android app is the home screen. Your application won’t run anymore!

Unless you have errors in your code, you might want to try killing the  Android Debug Bridge, it seems that it has problems from time to time. Do this from the command line:

$ adb kill-server

This will stop the Android Debug Bridge, and when you start an Android app the next time, it will restart.

Another tip: there’s no need to restart the Android Emulator every time you want to test changes in your app, just run it and it’ll be pushed out to the emulator. If you run the command above, though, you will have to quit the emulator to get everything to run smoothly…

Happy hacking!