Category: Tech

Mantra: “[Version control must become ubiquitous](http://subversion.tigris.org/servlets/ReadMsg?list=dev&&msgNo=128193)” — Branko Čibej

Subversion developers are gradually leaning toward distributed version control techniques [[1]](http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=128301), [[2]](http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=128301). However, they don’t want users to have to know it’s distributed. They don’t want users to know they’re even using version control. Lawyers, architectes, etc. all need version control, and often, they don’t even know that it’s possible. It also needs to be easy to do text searches on commit history.

> We do need to recognize that users are not interested in becoming version control experts, and we need to pay close attention to what they actually want, as opposed to what experts might want them to want.

> The reason Subversion is taking over the world is because it is tremendously
user-focused, and because it provides well-documented APIs that enable other
developers to write software on top of Subversion. We should copy what
we need from the decentralized systems, but remember that most users don’t know
or care whether a system is centralized or decentralized — their ideal system
is one they don’t notice. — [Karl Vogel](http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=128111)

Apparently, users really like the ability to “lock” files in the repository. How does that work with distributed version control? I don’t know.

[Eric Raymond praised the Subversion developers](http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=128106), although he believes the future lies in distributed systems like Mercurial.

Karl Fogel [replies to this and to Linus Torvald’s criticisms of Subversion](http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=128111). He does a great job of summarizing Linus’s talk on Git, and the things people want to do with version control:

> For many organizations, including open source projects, centralization is a
feature: you want changes (and branches) to end up in the master repository
sooner rather than later, so they’ll be visible to everyone, so they’ll be
backed up, so they’ll go through the central hook system, etc. It
focuses the community on a shared object (Ben Collins-Sussman makes this argument in
more detail at [http://blog.red-bean.com/sussman/?p=20](http://blog.red-bean.com/sussman/?p=20)).”

> A general tool configured to behave in a specific way is never quite
as natural to use as a tool designed for that specific use in the
first place. In other words, Subversion can — will have to — take
on some of the features of decentralized VC systems, but it will never
be as good a decentralized system as they are. By the same token, a
decentralized system can be configured to work like a centralized one,
but will never be as good at it as Subversion is.”

Individual [.svn dirs may go away](http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=128148), along with the ability to move a
subdirectory from a checkout somewhere else and have it still work. The reason? Better performance.

Phil Windley took notes on Jeff Barczewski on MasterView, Ara Howard: Ruby Queue, and Bayesian Networks in Ruby.

Mountain West Ruby Conference: JRuby by Charles Nutter and Ted Enebo
16 March 2007

Most of the developers in the auditorium have been Java programmers, and don’t
want to go back. Charles said that they have a hard time getting the message
out that JRuby isn’t about Java, it’s about Ruby, and they’ve aimed to make
JRuby as compatible as possible with Ruby.

Background: They’ve both been Java developers for the past ten years, and
their goal is to make Ruby a first-class language on the Java platform. They
didn’t start the JRuby project — they adopted it.

Ruby 1.8 Design Issues:

• Green Threading doesn’t scale across multiple processors/cores. The
  one-size-fits-all scheduler doesn’t fit all platforms where it runs. Although
  Ruby 1.9 will use native threads, there’s much work left to make it work on
  various platforms. Java/JRuby already uses native threading and scales across multiple processors and cores.

• Partial Unicode support. Ruby 1.9 will have Unicode support, but will bring with it other difficult issues (e.g. what happens when you concatenate two strings, each being in a different encoding?). In JRuby, one can use Java Unicode strings, or the Rails Unicode library.
• Slower than most other dynamic languages. Makes it difficult to sell to management. It’s a long term perception problem for the language. JRuby will allow compiling to bytecode, which allows HotSpot to do JIT optimization.
• Garbage collection is simplistic. JRuby uses Java’s best-in-the-world memory management and GC. Scales well to enormous applications and loads, and is battle-tested in deployments worldwide.
• C language extensions can crash the Ruby runtime, don’t necessarily interact well with garbage collection or with threading. JRuby lets you use Java-based extensions, which aren’t going to crash the VM.

Politically, it’s easier to get JRuby into an organization than Ruby, because
organizations have already accepted and deployed Java. JRuby is just a library for Java.

Most “pure” Ruby code runs on JRuby, and Rails mostly runs on it, although
only 90% of ActiveRecord passes unit tests. It’s easier to write JRuby code
than Java code. Perhaps Java is good for implementing libraries, and JRuby is
good for using those libraries for implementing applications.

JRBuilder/Cheri project by Bil Dortch lets you build Swing apps in JRuby much
more easily than writing Java code. Demo shown. Project is still in development.

NetBeans Ruby support is a one-man developer effort by Tor Norbye. His
progress has been impressive. Demo shown. Code completion, syntax
highlighting, built-in ruby documentations, go-to-declaration, auto-indent,
rename support, built-in interactive ruby shell (irb). By the way, Charles
uses vim, and Ted uses emacs. NetBeans Ruby uses the JRuby AST to do its work.

Speed. Interpreted JRuby is currently generally slower than Ruby 1.8.5, although some things are faster. They’re working on making it faster, and should be able to achieve comparable performance to Ruby 1.8.5. Compiled Ruby (bytecode) runs faster on the JVM than it does on Ruby 1.8.5.

Q: How can you make a JRuby app deployable so that people don’t know it’s a Ruby app or a Java app?
A: Make your ruby app into a jar file, and just double-click it.

Q: How easy or hard is it to deploy JRuby apps to servers?
A: Use Sun’s glassfish deployment framework.

mtnwestruby: Review of a Rails App by Marcello and Jamis of 37signals.com
17 March 2007

Almost everyone in the audience has used Rails. A little less than have write Rails apps for a living. I haven’t used Rails, and even if I had, it would be difficult to take notes on this presentation. I recommend viewing the video when it becomes available.

Marcello and Jamis recommend Kent Beck’s book on Smalltalk best practices and how to decide what code belongs where. They also recommend Domain Driven Design.

Why do you prefer the operator ‘&&’ over ‘and’? The use of ‘&&’ leads to fewer bugs. Consider the following code:

• return foo and bar # will not return what you expect
• return (foo and bar) # this will work
• return foo && bar # use ‘&&’ and ‘||’ because they’re more predictable in behavior than ‘and’ and ‘or’

Convention: A bad smell in code is seeing a chain of if..elsif
statements to check for error conditions. In this case, you probably want to
handle error cases with exceptions. For example, in Rails, myobj.save! will
validate data, and raise an exception when there’s a problem, whereas
myobj.save will not raise an exception.