ddfreyne

This appears to use the theoretical schedule, rather than real-time information. I live next to a busy tram line, and what I see through the window does not match what the site shows.

I created a register-based VM named RCPU, for educational purposes. You can find it at https://github.com/ddfreyne/rcpu. It has most of what you’d expect from a register-based VM, and even has video output (rcpu-assemble samples/video.rcs and then rcpu-emulate the resulting file with --video).

I intend to write up my findings, but haven’t gotten around to it yet. I do have slides for a talk for this project though: https://speakerdeck.com/ddfreyne/simulating-a-cpu-with-ruby

In case you couldn’t tell from the old-school theme, this web page hasn’t been updated since late 2008 (2008.11.28).

I have been using sublime-markdown-extended (https://github.com/jonschlinkert/sublime-markdown-extended), which has the nice feature of recognising and highlighting frontmatter blocks. Would love to see frontmatter support in the MarkdownEditing package as well!

The analogy given in the article is pretty accurate. The Smalltalk environment is unique in that it allows very easy access to the libraries, the IDE and the language’s internals (including the compiler!). The Smalltalk debuggers are among the best ones I have ever used.

(I’m mostly speaking out of my experience with VisualWorks, a commercial Smalltalk implementation, but other implementations are similar.)

I would greatly recommend everyone to give Smalltalk a try. The IDEs are pretty ugly and cumbersome, but don’t let that put you off. Get a feeling of the minimalism of the programming language and the pure form of object orientation. Dig through the code of the standard library — it’s quite easy — and check out the implementations of TrueClass, FalseClass, BlockClosure etc.

Unfortunately, many parts of the Smalltalk IDEs are horribly outdated and make Smalltalk a very poor choice of environment to use for production code.

Smalltalk lives in its own little world, and the tools that you’d normally use during day-to-day development are integrated in the IDE, and there is virtually no possibility of using external tools. The text editors are pretty bad, and you can’t use vim or emacs or Sublime Text. The Smalltalk VCSes are particularly horrible. For version control, you need to use systems such as Monticello or Store, both of which make me cringe just thinking about them again.

I also feel that Smalltalk coders get locked in into their environment. Many Smalltalkers that I have met are quite unfamiliar with what is happening in the outside world. Most of them have never heard of git, for example (and quite a few did not know what Subversion was). When an interesting technology enters the Smalltalk world, people seem to rush to reimplement it in Smalltalk (yes, there is STON — Smalltalk Object Notation).

These were the main reasons why I quit my Smalltalk job. A sad decision, but one that was unavoidable in the long run.

Smalltalk is a nice language and has IDEs with some very nice features that I would love to see in other environments, but it is also severely lagging behind in many other areas. I would like the Smalltalk community to be more aware of what is happening outside and build bridges. Without that mindset, I feel Smalltalk will simply fade out completely.

Source: I used to be a professional Smalltalker for almost three years.

There is a typo: foo2.ord in the first class Foo(T) example should be foo2.value.ord.

I admit I did fall into that trap once, long ago. I’m very aware of the consequences now.

The reason for writing the article, however, is because I have seen the same mindless behaviour with other people as well.

I believe it boils down to a matter of discipline.

If you say that you never randomly modify code in order to make it work (according to the tests), then that is great, and that is how every developer should work. However, my experience is that people who lack discipline (or face a looming deadline) tend to not take their time to properly reason about code and instead rely on the test suite to tell them whether code is right or not.

I (sadly) average 1 article written per 3 years, so there wouldn’t be much of a point in creating page views.

I have occasionally been tempted into the mindless code modifying that I described. That is in the past though!

More importantly, I have also seen this happen in professional environments. A very large test suite is very useful, but it is absolutely not a catch-all safety net.

I was using iTunes playlists as an example that switching to different parts of the UI does not interrupt playback.

I admit that the behavior is quite odd at first, but once you get used to it, it is really useful. It is the behavior you would expect in a desktop app — for example, you wouldn’t want iTunes to stop playing when you select a playlist, would you?

On FOSDEM a couple of years back, that question came up during a talk as well. IIRC, FreeBSD needs a VCS where they can delete changesets permanently, for legal reasons.

For distraction-free writing, I prefer vim in a fullscreen terminal.

A small mistake: “In Ruby, these functions are map, filter” — is incorrect; filter in Ruby is called select.

Seems to be inactive. It hasn’t been worked on since June 2010.

That app does not seem to be working correctly ATM, but you can use the commandline tools for converting: https://github.com/sickill/coloration

Another tutorial about pointers that I found quite nicely written is http://boredzo.org/pointers/.

I do not know the situation in the US, but there is a legal maximum of 12 minutes of advertising per 60 minutes in Europe, which boils down to a legal max of 20%. 50% seems unrealistically high.

Telling the browser to reload changed pages is a nice idea. I might steal that one for my static site compiler. :)

The same happened to TPB in Belgium: a list of domain names were blocked, but in response, depiraatbaai.be was created, which wasn't blocked.

Elisa blocks depiraatbaai.be, but creating a new domain name for TPB would be trivial.

DNS blocks are not effective.

If I were implementing this, I would go for an implementation where my Criteria objects are immutable. To me, it seems that code like

    crit1 = Criteria.new.where(:name => 'Jeff')
    crit2 = crit1.where(:age => 19)

I don’t mind mutability per se, but it needs to be clear what data is mutable and when it is mutated.

Hi, author of nanoc here. This morning I’ve been playing around with Stasis and it does look like a nice tool for building and maintaining simple sites. I like the controller-based approach!

Now, here’s a quick (and undoubtedly biased) comparison between Stasis and nanoc.

Stasis and nanoc serve a different audience. Stasis is simple, nanoc is powerful. If I want to quickly build a simple site, I might even use Stasis instead of nanoc… :)

nanoc, quite unlike Stasis, focuses on being powerful and flexible. Due to this, it is not as simple as other site generators. You can build any site you want with nanoc!

For Stasis to be more powerful, it would need to support metadata, custom filters and multiple representations… perhaps more… but then it would leave its original scope and people would say about Stasis that it is too complex. :)

There are a few more Ruby ones around. I have a list at [0] but even that one is outdated, as it does not include Ace or Stasis yet… and I’m not familiar enough with Python/Perl/JavaScript/etc to know the state of site generators there.

Writing site generators is easy and homegrown site generators will fit the author’s need best, so there you have the reason why there are so many. Mind you that quite a few are no longer actively maintained. For example, StaticMatic and Webby have recently both been discontinued (see [1] and [2]) and their authors recommend MiddleMan and nanoc, respectively.

[0] http://nanoc.stoneship.org/docs/1-introduction/#similar-proj...

[1] http://groups.google.com/group/staticmatic/browse_thread/thr...

[2] http://groups.google.com/group/webby-forum/browse_thread/thr...

The address book and dictionary icons have a different perspective yet sit in the same dock. Ack!

When I wrote nanoc about two and a half years ago, webby, staticmatic, jekyll, … did not exist, and I was looking for a way to publish a web site on a VPS with very limited resources.

I didn’t find anything that fit my needs. There were only very few static site compilers back then, so I decided to write my own (yes, I realise this expression is way too common). Soon after I released v1.0 in april 2007, other static site generators started popping up: StaticMatic and webby had their initial release a few weeks later.

Yes, there indeed is a lot of duplication in the static site compilation world. On the “about” page on the nanoc site, I give a list of static site compilers written in Ruby. The list is likely incomplete, even though I try to keep it up-to-date as much as possible. It also only contains site compilers written in Ruby, and omits site compilers written in other languages. The list currently contains the following:

* Hobix

* Jekyll

* Middleman

* nanoc

* RakeWeb

* Rassmalog

* Rog

* Rote

* RubyFrontier

* StaticMatic

* StaticWeb

* Webby

* webgen

* Yurt CMS

* ZenWeb

The diversity in static site compilation tools is huge. Static site compilation newbies are likely to be overwhelmed, and this is not a good thing. Can we fix this, please?

About a year ago (I don’t recall the exact moment), I informally contacted Tim Pease, author of Webby, and asked whether he would be interested in combining our efforts and merge nanoc and Webby. He unfortunately had no interest in doing so at that time (I’m not sure why).

I believe that combining the individual developers’ efforts is the way to go here. Every static site compiler out there has its own strengths and weaknesses. If we want to get rid of those weaknesses and combine those strengths, these projects need to be merged and individual developers need to work together. There are three goals that can be achieved this way:

1. Combine the individual tools’ cool features.

2. Get rid of weaknesses by seeing how other developers approach the issue.

3. Reduce diversity and make it easier for newbies to jump in.

I have no plan of action describing how to approach this problem yet. I have little experience as project lead for open-source projects; few of my open-source projects have dedicated contributors. Given that the other static site compilation tools are one-man efforts as well, I suppose that their developers have little more experience than myself (apologies if I’m wrong).

So, if you are the developer of a site compilation tool and you’re inspired, do contact me (you can find my e-mail address at stoneship.org/about) and we’ll see how we can tackle this problem. Time for some brainstorming!