Just yesterday I started laying the pavement for using Ruby at work. I didn’t want to cough up a few hundred for a dev license of Ruby In Steel, a slick Visual Studio plugin.  My first instinct was to dual boot a flavor of linux. Ubuntu’s not cleared for work, but Centos (& Redhat) are. The Centos install will have to wait until I torrent the DVD at home later this week (internet at work is low bandwidth). Alternatively, I can go with VirtualBox and emulate my way to happiness.

I remember first setting up Ruby at home on my then Vista system and groaning over failed native gem builds which finally prompted me to jump to Ubuntu (among many other issues). Going through the usual hoops, JDK, Netbeans for an IDE, Ruby one click installer everything went smoothly. Then I hit a road block:

gem install json

ERROR:  http://gems.rubyforge.org/ does not appear to be a repository
ERROR:  could not find gem json locally or in a repository

It couldn’t find the json gem (or any others).

Turns out I’m behind a universal proxy, thanks to Google search and stack overflow for clearing up my issue.

Here’s the fix in a comment under that answer:
gem install –http-proxy http://proxyserveraddress:proxyport _name_of_gem_

Native Gems

Now what I’m really concerned about is building native gems on windows and debugging what goes wrong. Most native C gems leverage gcc on Linux (and lots of other stuff). There’s a mingw port of gcc for windows, and there’s also cygwin, but I’m leery of trusting either of these alternatives to work flawlessly. Luckily Scott Anderson posted a useful trick for debugging native extensions at Geeksharp.com (thanks Scott). You gotta love the ability of hackers to figure something out, and share it with the world rapidly.

I’ll update my progress and experiences with Ruby on Windows over the next couple of weeks.

Who likes waiting for more complex programs to run?

In doing some research on fast dynamic programming languages, a couple of great finds caught my attention. I’m seeking a language that feels like Ruby but can run natively faster than using the MRI for the types of problems I like to work on (some numerically intensive). Alternatively, I don’t want to waste time with premature optimization. I am looking for a development language that is easy for me to create in, build on, and fast to execute, and finally has the easy to read syntactical feel of Ruby (I often reread my own code to figure it out months/years later). I’ve looked at Scala before, but have found much more enjoyment in Ruby coding. My fear is that a faster execution environment will detract from the qualities that endear me to dynamic languages (I come from c++ my day job’s default, so all of this is gravy to me). JRuby has shown some promise as well as the underlying tools (Duby) that are used to make interpreting Ruby on the JVM a more enjoyable process.

Q&A on Stack Overflow

Fortune smiled on me early this morning. I came across a couple of Stack Overflow answers which I appreciated on several levels. Over the past week I’ve grown accustomed to waking at 4 and searching for topics that have been bothering me. If the meritocracy of dynamic programming (features over class hierarchies) and malleable language structures call to your creative interests, you may need:

a) psychological help or

b) a damn good dynamic programming language

The first question “Are dynamic languages slower than static languages”. Jorg W Mittag’s well crafted response (here’s an excerpt):

In general, running well-designed code on well-designed high-performance execution engines will yield about the same performance, independent of whether the language is static or dynamic, procedural, object-oriented or functional, imperative or declarative, lazy or strict, pure or impure.

In fact, I would propose that the performance of a system is solely dependent on the amount of money that was spent making it fast, and completely independent of any particular typing discipline, programming paradigm or language.

The second question “What’s the difference between Duby and Juby and why would I need either of them?” has several parts:

• “What’s invokedynamic and why does Duby “need a playmate”?”
• “Could someone elaborate a little bit more on what this distinction is about?”
• Why do we need (need!) another Ruby-related language? Or, rather, two more Ruby-related languages?

and another great answer from Jorg (2 snippets):

2. Could someone elaborate a little bit more on what this distinction is about?

Duby is statically typed, Surinx (which is the final name for what was for a short amount of time called Juby) is dynamically typed. That’s already all there is to it.

Actually, there is one small detail as a consequence of this: Surinx syntax is a strict subset of Ruby syntax, i.e. every syntactically valid Surinx program is also a syntactically valid Ruby program. Duby OTOH is almost a syntactic subset, except for its mandatory method parameter type annotations:

def foo(bar => Integer, baz => String) => Array
# …
end
3. Why do we need (need!) another Ruby-related language?

Now, the funny thing is, Charlie came to Ruby, because he didn’t like his day job, doing Java development. And now, he still writes Java code all day long! Of course, he doesn’t like that, and so he was looking for another programming language in which to implement the core of JRuby. One option would certainly be to just write it all in Ruby, but with metacircular implementations there usually comes a point of diminishing returns, where the implementations degenerates into academic masturbation. It would certainly make sense to rewrite the libraries, the ahead-of-time compiler (actually, that’s already being done) and some of the core classes in Ruby, but some parts of the engine core are better written in something closer to the execution model of the JVM itself.

Charlie was looking at the available options: Scala, Groovy, Fan, Clojure, Nice, but all of them had a significant disadvantage: a fairly large language runtime. The size of the JRuby runtime is already a big problem in terms of memory consumption and startup latency (especially compared to MRI or YARV and even more so if you actually include the JVM itself in your measurements), and rewriting it in a language that adds its own runtime to that weight is simply a no-go. Unfortunately, there was no programming language which satisfied the two basic criteria Charlie was looking for: no runtime and compiles to JVM bytecode that is at least as efficient as the equivalent Java.

So, he decided to create his own. The reason why he chose to use a syntax similar to Ruby, is actually quite simple: he didn’t need to write a parser for it, Duby just uses JRuby‘s already existing parser with one minor modification to support method parameter type annotations. (Actually, he also likes Ruby‘s syntax, that was of course also a factor.)

Where are Programming Languages Going?

What I took away from my morning readings is that unorthodox optimization is already happening. People are selecting languages where they can quickly express themselves, and comprehend structures and flow easily. They’re even going so far as to adapt these “syntactically pleasing” languages and highly dynamic forms to faster compilers (Just in time compiling on the Java Virtual Machine, or even gcc)

The most popular and useful programming languages of the next ten years will share some of the following characteristics:

• Super Simple, Lightweight, & Easy to Get Started: the lighter the syntax and language, the more inviting it is to new programmers. New programmers come from all backgrounds and specialties. They bring their practical domain expertise to bear on problems dedicated hackers have a hard time understanding
• They will be net native. The most useful languages will be useful anywhere and everywhere on the web within browsers, JVMs, Javascript Optimizers, etc.
• Super Fast: programmers are nearly always subject to premature optimization. I do it unconsciously, and it’s a terrible habit. Of course there are mistakes aka “you’re doing it wrong” (usually made when underlying structures aren’t understood). If you’re trying to solve a problem, make the solution your first priority, then iterate on speedups after you have true representation of the data flow and usage.

The machines that are first invented to perform any particular movement are always the most complex, and succeeding artists generally discover that, with fewer wheels, with fewer principles of motion, than had originally been employed, the same effects may be more easily produced. The first systems, in the same manner, are always the most complex.

A quote from Adam Smith on industry.
And Tyler’s reponse (the source of the quote and inspiration behind this post): “reminds me of web development”.
Right on with refactoring magic, because hindsight is 20/20.

True Specialization Means Empowering each User

The ideal interface to collaboratively created databases and services is one perfectly suited to the changing needs of the user. Developers tend to isolate the view, controls, and data into different code sections (see more on MVC. This approach lends itself well to one where users are in charge of their interface, removing all non-essential information. My ideal evolution of this architecture is one in which the user can customize all design sections of a service to their particular needs, but our tools aren’t quite advanced enough yet.

A little about Adam Smith

Adam Smith was and continues to be an influential author long after his time. His prescient and detailed motivational philosophy has left a lasting legacy. An echo through time, resonating truth of value and principle.

Adam Smith (1723-1790) was a Scottish moral philosopher and a pioneer of political economy. One of the key figures of the Scottish Enlightenment, Smith is the author of The Theory of Moral Sentiments and An Inquiry into the Nature and Causes of the Wealth of Nations. The latter, usually abbreviated as The Wealth of Nations, is considered his magnum opus and the first modern work of economics. Adam Smith is widely cited as the father of modern economics.

For further reading explore The Wealth of Nations.

I’ll leave off with another quote of Adam Smith’s. Within it he alludes to the invisible hand of motivation, interest, and intention. Pay careful attention to how Adam concludes that individual motivations result in outcomes they had not consciously considered. (I see some overlap of this to the Nash Equilibrium, and competing strategies find balance).

Every individual…generally, indeed, neither intends to promote the public interest, nor knows how much he is promoting it. By preferring the support of domestic to that of foreign industry he intends only his own security; and by directing that industry in such a manner as its produce may be of the greatest value, he intends only his own gain, and he is in this, as in many other cases, led by an invisible hand to promote an end which was no part of his intention.

The bug tax is a form of friction that increases with the pace of development. For each new feature added, your software gains a number of new bugs. Minimizing the time your team spends bug chasing results in greater productivity, and coincidentally more time to add new features (which introduces more bugs). Good job, you just made yourself more work.

There is a well known question software developers face. Is additional utility worth the complexity and cost in debugging or redesigning existing structure? It sits at the forefront of every serious designer’s mind, and when increased functionality is favored too much we call it feature creep. This concept transcends software design and is evident in just about any project design (my blog layout is a perfect example of feature creep with information overload).

These bugs are introduced by state complexity and the limitations of individual developers to hold entire applications, all dependent libraries, and there interactions in mind simultaneously. On my best day I can keep two large applications and many of their nuances in mind, add a third and everything falls apart. In fact if I’m working on just one, I’m much more productive. Let’s review state complexity briefly.

Exponential Network Interaction Growth

Say I have one type of data structure and two possible states (on or off). The state complexity of a single structure is nice and simple (size 2). Scaling that structure is a matter of geometric growth (wiki reference). Add N more instances of that structure and I’ve added two to the N possible states to be concerned with (this is how numbers are described with binary data). Now introduce one additional interaction or state and expand the number of total states many fold (an additional base state causes system expansion to 3 to the Nth power unique states).

Why it’s not that bad

In practice this is not always as terribly complicated as it sounds. If you have high confidence in your design’s current functionality, adding linear increases to complexity doesn’t “break the bank” unless you are already at a resource ceiling. Resource limitations of bandwidth, acceptable delay, computer memory, and the most important developer neural ram . You can buy more hardware, but each developer’s mind is memory limited. New team additions require familiarization with the project, and this is an ongoing and predictable cost.

If you are working with solid software developers, they’ll have intense practical heuristics which help pair down massive complexity to manageable levels. If your team rigorously tests software, the bug is almost certainly in the latest software addition. But it’s also possible that the latest features reveal existing defects or design limitations.

When is an Additional Feature Worth the Bug Tax?

According to one of my favorite coding authors, who has extraordinary enthusiasm for startups, Paul Graham suggests (in Wealth) that the best path for a startup project is the steepest ascent (which reminds me of conjugate gradients).

Use difficulty as a guide not just in selecting the overall aim of your company, but also at decision points along the way. At Viaweb one of our rules of thumb was run upstairs. Suppose you are a little, nimble guy being chased by a big, fat, bully. You open a door and find yourself in a staircase. Do you go up or down? I say up. The bully can probably run downstairs as fast as you can. Going upstairs his bulk will be more of a disadvantage. Running upstairs is hard for you but even harder for him.

Now it’s time I get back to debugging at Victus Media. We introduced some bugs while fixing others last night.

Related Links:

• Protect Your Peace of Mind, Construct an Optimal Workspace
• Bionic Office by Joel Spolsky

But Mark what’s a terminal?

If you’re unfamiliar with older computer architectures here’s the low down on terminals. Back in the olden days, when the Internet was a gleam in engineers eye’s (and even further), most business and educational computer system architectures consisted of one or more mainframes/super servers, and many terminal nodes. Terminals had limited memory and functionality but were capable of directing resources on a heavy hitting server. Terminals were cheap and would allow many users to access central processing systems. Meanwhile home computers (the desktop) were just coming into existence (commodore/ vic20, TI99). In parallel both servers and desktop systems evolved. Eventually, in most businesses the desktop prevailed as a more useful node than the dumb terminal.

The web has captured many of our imaginations. And Google percieves (among others) a user need for dedicated portals to web services. In effect Chrome OS will allow for advanced terminals to one super mainframe of information, the Internet.

Pros and Cons of Chrome OS

The advantages include simplicity in administration, security, and portability for any browser OS system. The disadvantages include a lack of localized resources (minimal local caching), and reliance on connectivity for almost all functionality.

We use a variety of systems: a desktop, laptop or developer capable smartphone. The smartphone merges functionally with larger devices when I can code comfortably on it, Paul Graham mentioned this need recently. My preference is a full functioning OS with an optimized browser. Then I get the best of both worlds.

Quick Top Level Description

If you are new to the Chrome OS, or would like a refresher on the current project vision this video should help you get an idea of the design direction of the Chrome OS.

See an early demo version

This is a longer video (just over 11min) that shows a version of Chrome OS in action.

Gems Gems Gems

The first barrier to entry to ramping up on RoR (Ruby on Rails) was setting up a build environment. I found several windows friendly developmet options. Netbeans has an install. Steel Ruby has a visual studio variant, Instant Ruby creates an environment you can drop rails projects into (instantly ), and Ruby Forge has an executable for windows machines. I opted for the Ruby Forge windows exec after trying the other routes to varying degrees of success. Primarily because it almost works (there’s no shuffle! Array function on the RoR Ruby Forge version, or my environment still has problems), it’s command line driven, and I know where the common install/gem folder is.

Let me warn potential windows RoR coders that while all of these options may work to varying degrees, if your ultimate server destination is Linux Apache, you may save a lot of headaches by setting up a dual boot Ubuntu installation (today’s plan for me). After running into the bug with shuffle! and spending time finding and understanding it, your very limited learning and development time would be better served by avoiding the additional complications introduced with a different OS. Keep in mind I had a much more learned co-pilot helping me along in understanding using Adobe Connect.

Darn GEMS!

There are inconsistencies in gem names, versus the gem packages. This is to avoid name conflicts because gems sit in repositories on public facing web servers. I also found several close variants of gem names that have subtle implementation differences. One of the pitfalls I fell into was in assuming I had to call rake, and pass all our unit tests. It turns out I assumed wrong. In the race to develop something that is valuable to users, we have opted to skip some of the long term habits Rails nudges us towards (I’m sure as time allows we’ll find our way to testing). So the tests weren’t setup quite right for our specific project (they were using sqlite a default database for rails while we use MongoDB, a new NonSQL database option).

MVC Directory Structure First Timer

MVC stands for:

• model (data and it’s handling)
• view (how we see it an other intermediate stuff), and
• control (algorithms, processing, application flow , the CPU of RoR?).

When you first construct a bare bones Rails app (rails hello) , the folder structure looks something like this:
C:\Users\Dude Jones\Desktop\My Dropbox\Mystuff\people>tree
C:.
├───app
│ ├───controllers
│ ├───helpers
│ ├───models
│ └───views
│ ├───layouts
│ └───people
├───config
│ ├───environments
│ ├───initializers
│ └───locales
├───db
│ └───migrate
├───doc
├───lib
│ └───tasks
├───log
├───nbproject
│ └───private
├───public
│ ├───images
│ ├───javascripts
│ └───stylesheets
├───script
│ └───performance
├───test
│ ├───fixtures
│ ├───functional
│ ├───integration
│ ├───performance
│ └───unit
│ └───helpers
├───tmp
│ ├───cache
│ ├───pids
│ ├───sessions
│ └───sockets
└───vendor
└───plugins

Here’s that same structure with files
C:\Users\Dude Jones\Desktop\My Dropbox\Mystuff\people>tree /f
C:.
│ Rakefile
│ README
│
├───app
│ ├───controllers
│ │ application_controller.rb
│ │ people_controller.rb
│ │
│ ├───helpers
│ │ application_helper.rb
│ │ people_helper.rb
│ │
│ ├───models
│ │ person.rb
│ │
│ └───views
│ ├───layouts
│ │ people.html.erb
│ │
│ └───people
│ edit.html.erb
│ index.html.erb
│ new.html.erb
│ show.html.erb
│
├───config
│ │ boot.rb
│ │ database.yml
│ │ environment.rb
│ │ routes.rb
│ │
│ ├───environments
│ │ development.rb
│ │ production.rb
│ │ test.rb
│ │
│ ├───initializers
│ │ backtrace_silencers.rb
│ │ inflections.rb
│ │ mime_types.rb
│ │ new_rails_defaults.rb
│ │ session_store.rb
│ │
│ └───locales
│ en.yml
│
├───db
│ │ development.sqlite3
│ │ schema.rb
│ │ seeds.rb
│ │ test.sqlite3
│ │
│ └───migrate
│ 20091111235941_create_people.rb
│
├───doc
│ README_FOR_APP
│
├───lib
│ └───tasks
├───log
│ development.log
│ production.log
│ server.log
│ test.log
│
├───nbproject
│ │ project.properties
│ │ project.xml
│ │
│ └───private
│ private.properties
│ rake-d.txt
│
├───public
│ │ 404.html
│ │ 422.html
│ │ 500.html
│ │ favicon.ico
│ │ robots.txt
│ │
│ ├───images
│ │ rails.png
│ │
│ ├───javascripts
│ │ application.js
│ │ controls.js
│ │ dragdrop.js
│ │ effects.js
│ │ prototype.js
│ │
│ └───stylesheets
│ scaffold.css
│
├───script
│ │ about
│ │ console
│ │ dbconsole
│ │ destroy
│ │ generate
│ │ plugin
│ │ runner
│ │ server
│ │
│ └───performance
│ benchmarker
│ profiler
│
├───test
│ │ test_helper.rb
│ │
│ ├───fixtures
│ │ people.yml
│ │
│ ├───functional
│ │ people_controller_test.rb
│ │
│ ├───integration
│ ├───performance
│ │ browsing_test.rb
│ │
│ └───unit
│ │ person_test.rb
│ │
│ └───helpers
│ people_helper_test.rb
│
├───tmp
│ ├───cache
│ ├───pids
│ ├───sessions
│ └───sockets
└───vendor
└───plugins

There are scripts that will populate subdirectories with ruby files. One that adds to the application, model and view folders at once is scaffold.
It looks like this on a windows prompt:

ruby script/generate scaffold person name:string password:string email:string age:integer

It creates several files of which I believe a few are key after reading some of getting started (I prefer to learn by doing, then going back to understand what I did worked or broke and why):

• The model support file is the Rails migration db/migrate/20091111235941_create_people.rb
• a model in app/models/person.rb
• a controller app/controller/people_controller.rb

The scaffold script also generates several tests (look for person/people above, a helper).

IDE

I used Netbeans, Visual Studio, and for editing Notepad and ScITE. Of all of these, I think I prefer Visual Studio the best for speed, style and responsiveness, but Netbeans is a good backup integrated development platform. ScITE was handy for quick editing though. I ran the server off of the console so I can see what messages (errors) it was printing out, instead of constantly have to reopen the log file. I suspect you will become quite intimate with log/development.log as you experience building your own Rails projects.

Check out what we’re up to at Victus Media, a cool dev build should be going live this week for Intelligent Advertising Media.

Don’t forget this handy Google Doc I started for diving into Ruby on Rails.

Most recently an estimation program I have worked with a little was sputtering nonsense outputs. After a couple of days of pulling our hair out we discovered the inputs were junk (good job Paul). Imagine this on a global scale, where interfaces expect specific data formats. How much of our time and energy is spent “bunny chasing” compared to new design efforts. Sometimes it is beyond the user to fathom the full capability and assumptions for an application. This is where simple yet comprehensive documentation comes into play, or the ability to contact the software experts directly (Twitter, email).

At the first level of documentation, describe what and how your software does something. Users aren’t mind readers, and even you are likely to forget the nuances of a large application months or years later. As the complexity of any application increases, the potential for hard to find bugs creeps up as well. The more internal states your application can potentially be in, the greater the chance that you haven’t tested them all.

Along Come Alpha & Beta Testers

I can’t overemphasize enough the importance of external testing. Just yesterday I caught Savendar asking for user feedback on reddit. Savendar had developed a coupon and deal search tool localized to your area. He got a bunch of great feedback and recognized areas for immediate change. Simply put, as a developer we are working and thinking most about functionality, and less about first impressions and assumptions of users. Early testing helps fill in this design gap, and probably gets a couple of testers excited about your offerring. I know when I test something, and make a suggestion that’s instantly implemented I get a happy feeling, especially when it helps that product or business take off.

We need to satisfy our creative itches by tweaking functionality and layering (Internet) applications. We would save time by balancing this experimental activity with knowledge of application breaking points.

Related articles by Zemanta

• Advantages of Agile Software Development for Testers (agile-software-development.com)
• What Do Testers Hate About Testing (slideshare.net)