Latest entries

Having professionally(!) been programming for a while now, I've run into this situation where I'm actually putting quite precise requirements on the tools I use to develop, both professionally (C++) and at home (CoffeeScript with NodeJS). Thus, after having seen some of the amazing benefits of big clunky IDE's for C++ (keypress to go to declaration/implementation) as well as some of its atrocious drawbacks (what slow, badly designed monolithic beasts of programs they are - but you have to use them with big C++ codebases because of the benefits), I have been hunting for good features for my home web development setup.

Got a spam bot set up to hammer the comment button here on clux.org it seems.
Hot windows serialz etc. Sorry if people's notification tab gets spammed.

Originally, I set in place an anonymous posting limit so that individuals can't spam anonymously (doing so even required a captcha), so this led to someone registering manually and bot-hammering from there. This wasn't a big problem, as I can still one click to delete all the comments of a user - and user registration is meant to be a more tedious process than that.

The annoying thing, is that both the actions that can be done anonymously requires breaking a captcha, and at this point mine is definitely broken as spam comes in anonymously as well. Which means, well, stronger captcha soon :/. In the mean time, user registration is temporarily down.

static pthread_t clux_thread;
int main() {
  //...ignored 5,000,000 lines here
  pthread_create(&clux;_bg_thread, NULL, Worker::clux, (void*)new Workspace());
  //...ignored 50,000 lines here
}

//worker_clux.cpp
static pthread_t clux_bg_thread;
Changeset * clux_work(BACON * bacon, METAL * metal) {
  metal->listen();
  
  Code * code = new Code();
  while (true) {
    (stash.push(*bacon)) ? ++code_quality : code_quality--;
    Changeset * chng = code->commit(new CIMsg(code));
    if (code->merge_and_build(&clux;_bg_thread)) { //transactional. switches to bg thread while build blocks
      code->push();
      return chng;
    }
    code->rollback();
    code->append(new Code(code_quality));
  }
}

void * Worker::clux(void * workspace) {
  Workspace place = workspace;
  workspace->init('ubuntu');
  while(workspace->activate()) {
    METAL metal = (conservative) ? clementine('/home/clux/Music', 'Opeth') : chrome('grooveshark.com', metal);
    BACON * bacon = (BACON*)falloc(2*sizeof(BaconContainer));
    
    while(bacon->in_fridge() && metal->find())
      myProduct->development_branch->document(clux_work(bacon, &metal;));

    if (!leaving_time) //above loop exited early => no network or food
      marioKart->advertise()->play();

    int hours = (day_num%7 >= 5) ? 56 : 16;
    workspace->deactivate();
    sleep(hours*3600*1000);
  }
  exit(-1); //require manual startup
}

void * Slacker::clux(void * workspace) {
  while(true) {
    (internet && !num_bugs) ? internet->browse() : clux::ponder();
    if (irc->uptime()) (mood=='meh') ? irc->troll() : irc->chat();
    if (marioKart->advertise()) marioKart->play();
  }
}

As a person who has replaced all sports with competitive gaming vods, it displeases me that most of my gaming time is spent playing casual, mostly graphics oriented games with low gameplay value. As compensation, I have speedrunned N, Trine, Minesweeper, TrackMania and done miscellaneous Quake trickery over the years. This has given me enjoyment and some vague sense of accomplishment for doing something few other have done well. Innovating in a competitive environment feels particularly good when you finally pull it off.

It's therefore interesting to note that few of these games even include a web based hiscore or achievement system - or sometimes even a proper timing system. But the one thing they all have in common, is smooth, responsive, and mostly fair gameplay. It seems that these days, however, this kind of achievement based gaming is mostly being falsely fabricated through steam/xbox achievements (of usually very easy games). TF2, for instance, has almost 400 achievements ranging from very easy, to simply tedious or requires several people. This really isn't a substitute, but writing simple console scripts to automate parts of getting some of them was.

Interestingly, however, most people responded very angrily when I posted about this, lamenting that I had somehow tricked my way into getting absolutely meaningless achievements. Seriously. Achievements are usually not hard, often do not feel like achievements, whereas exploiting the system might. You may disagree with this, and that's fine too. The point is that what resonates with you with some sense of achievement is relative to your personal context.

With respect to gaming I have two defining properties to point out; an unusually long history in scientific academia, and much competitive Quake 3. These two factors define on some over-generalised level what I'm proud of: clever trickery, or exhibits of pure skill.

It's therefore with joy that I actually found hard achievements that rewards both: The Super Meat Boy no-death run achievements. They require excellent micro, but they also reward tricksters by allowing situational character switching. It's a first for me to see developers take advantage of this so well with built in achievements (though, I should criticize them for also destroying speedrunning in a very well-suited for speedrun game by including a broken hiscore system, but that's another matter).

While these can become great personal goals to beat, they appear widely unpopular elsewhere; only one no-death run made it into X360 because they were considered too hard for instance. There is clearly an element of danger here. Built in achievements are addictive and the difference between what I sought out to what achievements represent is that they present you with a goal, not the other way around. You feel like you should be able to do many of them, and so you try. This is very natural with the right mindset.

Regardless, I advocate that people should just have to learn how to moderate their gaming time (vs. claims about addictiveness), and accept that there will always be players better than you (vs. too hard claims), but I know how persuasive such incentives can be. On one hand, I did all the meat boy no death runs mentioned above, but I turned down the opportunity to do the two last bandage girl no-death achievements (cotton alley) because they felt too extreme. I would call it self-control, but frankly I just got bored. Good games are few and far between these days though, don't shit down other people's necks just because their addictive. We keep coming back because they are fun, not because we require our fix.

zombie boy took 10+ hours, that was the end of my patience

This is apparently what happens when I experiment with new technology for months and don't post anything. I can't say much more than that I am thankful I at least got one good dump out on the internet. Heh.

Anyone stopping by here are exempt of reading any of this of course. The following 7 posts (which is the likely number of unread updates given there's been, what, 4 months) are a short version of my experiences with certain bits of web technology. Essentially, my road from
1. PHP.CodeIgniter.SQL
2. Python.Django.SQL
3. Python.Django.MongoDB
4. JavaScript.NodeJS.MongoDB.
+ My experience randomly changing to a the Colemak keyboard layout. I am very happy to see that sufficient amounts of my rebellious spirit remains to do something so unnecessary. Something that ultimately just annoys the fuck out of everyone.

Anyway. According to the age old Irenicus quote on my profile; this is, and always has been, my manual brain organizer. It's likely not useful for you, but you are allowed to peek in for.. I don't know, 2050s historical reasons, perhaps you even need to document a hitherto undiscovered neural condition!

It's interesting to imagine what your legacy will be given the current evolution of the internet. I bet that at some point, there will be some sort of steam-like achievement to do have to read through certain internet journals to unlock a particular secret. I hope for your sake that journal is not mine.

but a man can dream..

A requirement of the current NodeJS versions, is essentially, that you develop on Linux. I say Essentially, because it's technically possible to build with Cygwin, but it also technically possible to get your dick trapped in a box opener. My point is, don't do it.

I went for the latest Ubuntu, mostly influenced by brothar's success with it. I was so happy with it, that it immediately overtook my daily windows usage. In fact, my windows usage is now limited to photo editing and gaming time. Things just take so much less time here. I can:

1. Open up a terminal, get the programs I want immediately by typing sudo apt-get install X, Y, Z. No browsing kat.ph, manual unraring, obligatory virus check. It just works. Thought Chrome handled updates well on Windows? Try Linux. Also: fuck everything about windows update, and it needing to boot all the time.
2. For a calculator; open up a terminal. Use the python interpreter.
3. Need another terminal? Install Guake. Handles multiple tabs; Ctrl-T for new shell, Ctrl-W for close this shell, Ctrl-Left/Right for moving between tabs. It's persistent. Pops down (with last active tab shown) with the press of a button. If you're a Quake fan you'll use the console button, because that's exactly what it looks like, but with adjustable opacity.
4. Want a mIRC replacement? install XChat, no need to register (as with everything).
5. Replacement Music player / Video player? No need. Clementine / VLC. The best simple stuff that just works for Windows work here as well.
6. Task manager? The ps command can list. ps -A | grep chrome will give you the list of running chrome processes. sudo kill is consequently fun. "Are you sure [, windows user,] that you would like to end this process?" GTFO, KILL. Enter. Done.
7. Copy an entire folder with permissions? Without dragging the mouse? tar cf . - | tar xf - -C /target/dir. This compresses everything (with tar) in the current directory, pipes it to stdout, from which tar extracts it to the target directory. Might seem convoluted, but it reflects many of the fantastically helpful things you can do in the terminal. Send info from and to different programs in one command.

This is my discoveries from less than a month of use. It looks and feels great, and there's replacements for everything. Except games. So dual boot is perfect. It creates isolated environments where one's productive, and the other is good for fragging. My development time + enjoyment is up, and gaming time is down / more concentrated.

hax++

Much of my previous JavaScript experience was highly coupled with the PrototypeJS framework. This operates by extends many of the built in prototypes so that you can code beautifully in an object oriented way by chaining. Unfortunately, extending built in prototypes is very bad behaviour, so I have since jumped the jQuery bandwagon, but applying UnderscoreJS for getting chain like helper methods. So far it is less error prone than what PrototypeJS was, and animations actually queue up in a sensible way (something I could never get right for all cases with Prototype's animation framework Scriptaculous - as can be seen by hovering/unhovering the clux.org logo intensely).

Additionally, UnderscoreJS includes a template helper function (source looks identical to this). Which means that I could theoretically use it both client side and server side. I have, however, decided to take it to the next level. I will only render templates client side.

It's remarkable that I can even consider this, but browser progression has indeed now reached levels that mean developers can simply discount users without JavaScript. But while it can be dangerous (one missing comma, and your page could be unusable), with proper testing the benefits far outweigh the dangers.

1. Everything except the first response can be done in low-bandwidth JSON. The first response requires just a little more. Prepare a 10 line, one-size-fits-all template with a script tag that dumps a stringified object right inside. With proper handling this can be used to render it on the client for the first response as well.
2. With a REST interface, you can simplify your code so much that creating a mobile version of your site is a matter of just changing some templates/JavaScript. I use Spine for interacting seamlessly with my backend (because it is essentially a lighter version of BackboneJS).
3. With good use of script loader/minifiers/compilers, you could theoretically serve only one highly compressed file, and load in others pieces of JavaScript as you would need it. Minimizing data transferred and number of HTTP requests. RequireJS combined with UglifyJS seems the way to go.
4. With HTML5 history, you can make function like a normal website where urls are bookmarkable as well. The implication is of course that every url you create must map onto the one you are getting JSON requests from. But this should be trivial. Simply serve the short template described in point 1, and embed the normal JSON response in the script tag. Catching it is as easy as (req.xhr) ? res.send(c) : res.render('layout',{c:c}); with Node.

a few years ago, this would have been horrible, now it's amazing.

One thing you notice pretty quickly with MongoDB is that most object relational/document mappers (ORM) tend to be useless. Django's internal one was attempted patched for NoSQL, but when you cannot even embed documents into others, you have essentially downgraded to a poor-man's SQL. MongoEngine, the most popular ORM for Python immitates Django's model style, and allows you to define base Documents subclasses which can reference (contain) EmbeddedDocument subclasses. It works the way you should expect for simple queries, albeit a bit weird for .save() where when only a partial query dictionary is supplied, it will actually overwrite that document destroying the missing keys.

This can be be bypassed by other methods, and overall MongoEngine works reasonably well. I was able to add queries, alias my table field names to shorter ones to save disk space (but get them back to understandable ones after mapping), but for every embedded document, MongoEngine added 3 extra fields to that corresponding JSON object. From what I gathered, it is some backwards effort to resolve the internal MongoEngine document subclasses from these fields. It worked, but it meant that every element in the base collection, and every sub element which was defined with an EmbeddedDocument, would have 3 useless fields containing the exact same info everywhere. If you have N embedded documents in your base documents, that means 3xN fields of waste per query. That's a fuckload of waste.

Additionally, getting manual connection to do a full-out manual query (definitely needed for advanced sites/optimization) feels extremely hacky. Thankfully, I am not dealing with mediocre Python ORM anymore. If anyone is considering that, they should really use something lighter lest they have to figure out what horrors lurk beneath. But keep in mind that there are no non-blocking MongoDB drivers for Python.

Enter Mongoose. Much less hidden code execution, transparent class like schema's with self-defined getters/setters and validators. No extra fields in your database, almost same syntax as the mongo shell, and manual queries a lot easier to inject. I wish there was more to say, but it just seems to work without side-effects, which is what an ORM's supposed to do. In fact, it's the only thing it's supposed to do. It's a helper library!

tl;dr: MongoEngine bad, Mongoose good.

I very recently concluded, that as everything was very suboptimal with the Django, and especially the MongoDB usage combo, I should go for something else. This was not a very hard decision, as thankfully most of my code from my Django project was client-side JavaScript. I could turn to newer and hipper python frameworks like Twisted to encroach upon some of the newer web frameworks' performance, but with no asynchronous Python drivers for MongoDB, it seems I would have to learn yet another scripting language - or return to PHP.

Turns out there's another way now. JavaScript.

The reason for why DOM scripting is so good with JavaScript, is that it's completely event driven and asynchronous. One thread running from top to bottom, simply attaching callbacks to events, and with a sensible hierarchy of events so that events bubble up, i.e. a click on a ul > li > h1 will trigger the most specific match first, then eventually any click listeners on li, ul, and body unless cancelled in the innermost matches.

NodeJS maintains exactly this event loop in its JavaScript interface, but uses it to actually implements a socket thread pool underneath (in C), for you to build a web server upon. It generates a lot of buzz these days, and with no thread per connection overhead from Apache, it gives you a remarkably simple way to create a web page with amazing performance. I mean, it's not quite C or Erlang like yet, but for an easy to write scripting language, it is astonishing. Take it from me, who am now actually coding multi-threaded C++ professionally (albeit not very well); this shit is hard, very error-prone, and very slowly progressing. It should only be done if you have plenty of time to do it, or you are an expert. Thankfully, I have plenty of time for it, with concentration inducing Grooveshark playing in the background.

This puts me in a peculiar situation. Everything I do in my own time, is done in JavaScript. NodeJS runs Google's highly efficient V8 JavaScript engine, MongoDB runs Firefox's SpiderMonkey engine, and the result is that to me, everything runs smoothly. The native MongoDB drivers runs problem-free, asynchronously, with the same syntax as the mongo shell. Most importantly, however, the rise of JavaScript compatibility in browsers is now so high that developers can justify complete reliance on it. Goodbye to the days of replicating validation and rendering twice. Better browser support plus universal JavaScript allows for code reuse!

My server code is, at the moment, shorter than what I had in Django, but already I have more functionality. Clearly, the challenges lie elsewhere. NodeJS is easy, and brilliant. That said, perhaps the most useful thing I have learnt recently came as a result of this interactive JavaScript tutorial. Don't miss out.

*waves goodbye to Apache*

PHP is ugly. This was my motivation to jump on a new language and a new way to program for the web. I bought the fourth edition of 'Python: Essential Reference' and read through the entire thing to get a good overview of the language. It thought me a lot about concepts that I just managed to barely use (by imitation) in PHP, and opened a world about what is actually possible.

Python is neat. List comprehensions, generators and iterators are amazing abstractions. List comprehensions in particular, so close to the mathematical set syntax. For example: sum([x*x for x in range(1,100) if x.is_prime()]) would calculate the sum of the squares of the first 100 primes if you had defined the is_prime function. This and its consistently forgiving use of the in operator would be a selling point by itself. But classes were also implemented fantastically.

So, I ought to make my next site in Python's most popular framework; Django. With 1.3 just on the horizon, it was truly exciting times. Django was clearly a very ambitious project. You defined all your database tables as model classes so that validation would be completely described by these models. Also, all forms you would make could inherit from these models, so that if you had assigned a table element to be a bool, it would automatically suggest itself as a checkbox on the inherited form. All the model classes also acted as the frameworks ORM, so that each model's get/set methods would map easily onto database interaction, as say User.filter('admin',true)[0:10] would simply retrieve the first 10 admins users. You could also populate the result of a form post by a one line User(request.POST['userform']). All this meant generating a first draft was remarkably easy.

Unfortunately, the positives end there. Making anything but a flat HTML page, requires you to do a lot of digging in its codebase for customization options. In particular; a lot of HTML is hard coded into their widgets. The worst I had to deal with was creating a 7-line subclass of a model widget just to get an extra character in between two fields (in SplitDateTimeWidget) and get different placeholder texts on each of them. All hardcoded HTML is additionally self-closing, so fat chance being HTML5 compliant. ForeignKey and Many-To-Many relationships for models aid basic SQL, but also makes everything less transparent and harder to optimize (no multiple insert code, hard to know how or when joins are performed).

While most these things are not hugely important, they reflect something fundamental in Django. It's a monolithic beast that ends up sacrificing code versatility for code brevity, and as a consequence, does neither for anything but very simple projects. Its ideas are admirable, and while the execution is less so, I still enjoyed learning how it worked those 3 months. However, I cannot in good conscience recommend it to anyone in 2011.

but fear not