The project that I’ve been working on, on-and-off for the last couple years is nearing completion. It’s a full stack software suite for ICANN Accredited Registrars. It’s modern, flexible, and has a RESTful API allowing all kinds of app integration for a Registrar.
The software design process on this has been a real treat. It’s quite a complex undertaking, including software that communicates with all the various TLD registries, deals with a ton of ICANN requirements, and still manages to focus on a clean user experience and a robust and simple to maintain software stack. Every level of the software is backed up by a full test suite, which should give us the flexibility to roll out support for the upcoming gTLDs quicker than the competition. (and with fewer bugs!)
We’ve just launched our announcement page at www.credrock.com. If you’d like to know more and stay up to date as we approach launch, please register on the site. And if you know anyone looking for new software for their Registrar, or just starting their own, send them our way.
So I’ve been using ActiveResource to consume a RESTful Rails API, and had embarked upon setting up forms for the ActiveResource web client. I’m a big fan of Formtastic, and have been using that for standard ActiveRecord forms for a while now, and figured I’d go ahead and try it with ActiveResource.
Well, just like the form_for helper, Formtastic relies on the the attributes specified by the object. With ActiveRecord, the attributes are pulled from the database when the object is initialized. ActiveResource, on the other hand, generates a pretty plain object upon initialization.
>> User.new()
=> #<User:0x102fd0e00 @prefix_options={}, @attributes={}>My first instinct was to go ahead and create the attribute accessors in my ActiveResource class by hand. However, as soon as I started typing out all those attributes by hand, I had flash backs of C# and knew I was straying from the Righteous Rails Path to DRY Salvation. (RRPDS)
I then realized that when scaffolding out REST Resources on the API side, Rails generates methods that serialize a new object to XML, which can be reached at /resource/new.xml. It seemed to me that the whole point of serializing a new object would be to make the attributes discoverable. The Rails docs for ActiveResource, however, are strangely mum on the finer points of populating the attributes, and all of the examples simply show passing in an attributes hash to the new method.
So then it suddenly hit me. Since the find(id) method simply makes a GET request to /resource/id, if I passed in ‘new’ as the id, it should do a GET request to the serialized representation of a new object.
>> User.find(:new)
=> #<User:0x102e541a8 @prefix_options={},
@attributes={
"first_name"=>nil,
"last_name"=>nil, ... }>So now I can simply pass Formtastic a User.find(:new), and I’m back to bathing in the glorious DRY light.
UPDATE: As of Rails 3.0, calling Model.build() will do the same thing as Model.find(:new).
Just tried this out in TextMate, and it works a treat. I think this is going to replace my use of HAML.
You’re also highly likely to hit the stack limit in Ruby with recursion, and I don’t think there’s a simple way to alter the stack size.
I may be wrong but if my CS classes haven’t left me yet I believe you will find this in all programming languages. Iterative algorithms always run faster than recursive ones.
I’ve become interested in recursion and functional programming lately in the interests of sharpening one’s saw, and was interested to see how recursion performed in Ruby.
Consider the following code:
require 'benchmark' def recursive_factorial(n) n == 0 ? 1 : n * recursive_factorial(n-1) end def iterative_factorial(n) (1..n).reduce :* end Benchmark.bmbm do |x| x.report("recursive:") { 10000.times { recursive_factorial 1000 } } x.report("iterative:") { 10000.times { iterative_factorial 1000 } } endYields the following benchmark:
Rehearsal ---------------------------------------------- recursive: 53.670000 2.560000 56.230000 ( 57.035829) iterative: 32.540000 2.330000 34.870000 ( 35.629017) ------------------------------------ total: 91.100000sec user system total real recursive: 77.420000 3.740000 81.160000 ( 88.844745) iterative: 41.870000 3.200000 45.070000 ( 64.231568)Considerable difference in performance. The iterative method looks a lot more simple and elegant too in my opinion.
(via fuckyeahcomputerscience)
Check out Kryder’s Law
I remember when I couldn’t imagine filling up the 40 MB hard drive on my Amiga.
When was the last time you saw a real computer screen in a movie? Usually in movies we get some dumbed down looking operating system, or some totally unreal user interface, like flying through a 3D city to access a file. I’m sure even in the far off future, navigating a 3D virtual world will not be an efficient user interface for most computer systems.
So it was with great joy that I watched the latest Tron trailer. If you pause it at the moment Flynn’s son sits down at the computer terminal, you’ll see a real looking NIX operating system, as can be seen above. You’ll notice that both iostat and top can be seen running. The version name in the screen is “Solar OS 4.0.1” which as far as I know is a made up system, but is probably a play on SunOS and Solaris. Additionally, the platform name says “sun4m” which would make it a SPARC workstation, which would make sense if this is a 20 year old system.
A client called complaining that she couldn’t access the company website. When I get there, this is what she had typed in the URL field: “the company website”.
A friend of mine once told me a story about when he was doing IT work for a local state election campaign. They told him that they backed up their entire user database every night…. on a single floppy disk. Nonplussed by this feat of engineering achievement, he asked them to show him how they did it.
Walking up to the computer, the diligent user proceeded to drag the shortcut icon for the access database to the floppy. See… backup complete!
I find it frightening that SQL Injection is still making the headlines. Back in 2000 we wrote a library for our ASP sites that took care of this. Yes, I said ASP. How is it that 10 years later this is still such a problem?
If you don’t think it’s an issue, check out this list of recent SQL Injection attacks, which includes the largest case of identity theft known in the US.
So what’s causing this, who’s to blame? In my opinion, it’s the developers, and the people who hire and perpetuate the use of such developers. Excuses of time, budget constraints, or my boss made me do it don’t ring true for me. First of all, there are enough libraries and frameworks out there that make SQL Injection a thing of the past and a simple fix. I primarily use Rails for my web applications, and I’d have to try really hard to expose a SQL Injection vulnerability. And when there is a case in which using a database persistence library is a no-go, I spend the time to abstract out the persistence layer myself and include sanitization on all the inputs.
I would never trade such basic security measures for time or budget constraints, and if a client or employer ever asked me to do so, I’d explain that things could take an extra week or two now, or you could expose all of your valuable data for theft and destruction. In reality, such a discussion would not even come up, because the SQL abstraction and sanitization would be built into the timetable from the get-go, and is always non-negotiable.
So usually it comes down to the developers, the ones writing the code. In my experience, it usually comes from ignorance or laziness. On the ignorance side, sometimes you’ll find a developer who has always just “gotten by” as a programmer and their depth of knowledge doesn’t pass much beyond the basics they learned years ago, which includes writing SQL statements in their web pages. On the lazy side, it’s the pass the buck mentality. Arguing that time and budgets constraints are the cause is really an excuse for not doing your job as a developer, which includes educating business owners as to what needs to be done for a working and secure system.
Some of the blame does lie with those people hiring the ignorant and lazy developers though. In the end, you get what you pay for. We need to understand that software programming is becoming an ever more vital part of our society. It’s the foundation upon which much of our current civilization runs. That’s not something you outsource to the lowest bidder.
