For a while now, i’ve been looking for a nice and feature filled personal finance application for Mac OS X. The only promising one i found was GNUCash, although it required X to run which resulted in it being very clunky to use. It was also a nightmare to install, with it typically pulling in lots of dependancies in MacPorts which in turn took up lots of disk space - not exactly a plentiful commodity on my Macbook.
Just as i thought all was lost, i found this rather interesting page on the GNUCash wiki, which describes how to compile GNUCash along with the native gtk port, which is great as in theory i would get a nice native version of GNUCash which would be a bit less clunky than the X version - great!
After a few minutes of trying to follow the instructions on the GNUCash wiki, i thought “surely this could be simpler?”. So i decided to check out my old friend MacPorts, which just happened to include support for the native gtk port. All you need to do is… well, run this from the terminal:
$ sudo port install gnucash +quartz
Sadly though, it wasn’t that easy. Soon after i kept bumping into compile issue on compile issue. I even modified the Portfile’s to apply patches to the associated library’s. I almost managed to get it working… i even got the loading screen trying to pop up… until i finally bumped into this:
dyld: lazy symbol binding failed: Symbol not found: _cairo_quartz_surface_create_for_cg_context
Referenced from: /opt/local/lib/libgdk-quartz-2.0.0.dylib
Expected in: flat namespace
dyld: Symbol not found: _cairo_quartz_surface_create_for_cg_context
Referenced from: /opt/local/lib/libgdk-quartz-2.0.0.dylib
Expected in: flat namespace
Which safe to say, put the final nail in the coffin. Rather than spending even longer to try and fix this rather annoying linker issue, i gave up. After all, it was infinitely easier just to type this into my copy of Ubuntu Linux running in Parallels Desktop:
sudo apt-get install gnucash
… which left my with a hassle-free installation of GNUCash which actually worked properly. Although then again it was running in a vm window, but i guess that’s the price one has to pay for sanity.
Consequently i now know that no, it can’t be any simpler to install GNUCash with the native GTK backend in MacPorts. In addition i think i’ll wait till someone else iron’s out all the problems and makes a nice native GNUCash package for Mac OS X.
Sometime last year, i took a leap of faith and made an account on Second Life. In essence, i wanted to find out what all the fuss was about.
Initial impressions
So like any other person, i downloaded the client and logged in. After going through the typical loading screens and dialogs, i appeared on the “Orientation Island”. It’s basically a place all new users end up which takes them though the basic’s of using second life - like how to fly, how to build things, how to interact, and so on.
Interestingly, Second Life is not your typical MMORPG where you kill rats, undertake quests, and perform other menial tasks. Quite notably, you can do things such as:
Create and edit 3d objects
Script objects using the Linden Scripting Language (LSL)
Completely customise your character - you can even attach objects to your body to make furry costumes
Sell people your creation’s for linden dollars which can be converted to real currency
Buy and sell land
And so…
So in essence, its a virtual money making platform. I say money making as it was very evident that to do anything useful, you really had to spend some of your virtual cash, otherwise known as Linden Dollars. Need to upload a sound or texture? L$10 per item. Want to equip your character with some cool gear? L$$$. Want to buy some land? L$$$$. For reference, when i last checked it was $4.06 for L$1000.
Granted, you can pretty much go anywhere without having to pay for anything. But then it becomes a rather boring 3d chat client. Though then again, that is what it also doubles up as anyway. In fact, this video on YouTube pretty much sums up Second Life as a 3D chat client:
Unfortunately, due to the infamous breakin of linden labs servers, the password on my account was reset. This wouldn’t have been so bad, except that i couldn’t set a new one since there was no way i could verify the request (e.g i typed complete gibberish in the question field when i signed up), and thus i was essentially locked out of Second Life.
Onto OpenSim… and Open Source
Since i last managed to log into Second Life, a lot has changed. For instance, not long ago Linden Labs opened the source code of the Second Life viewer. Around the same time, an interesting open source project called OpenSim popped up which aims to re-implement the Second Life server code (along with the associated grid and login services), which means anyone can host their own Second Life simulation.
Like a lot of modern MMO’s, Second Life runs on a grid, so the simulated world is essentially split across several servers (typically referred to as regions). Each region simulates a particular part of the world. All the regions are supported by a small set of supporting services, which handle login, assets, and of course the interconnecting grid so everyone can walk between separate regions.
So after some further digging, i found this rather interesting project called DeepGrid. DeepGrid is essentially a freely hosted Second Life login & grid server. Anyone who hosts their own Second Life region (using OpenSim) can tell it to connect to DeepGrid and thus become part of the DeepGrid virtual world.
In plain English, they made their own Second Life.
I decided to have a look at this DeepGrid, so i made an account and pointed my client at their login servers. Sadly though, i bumped into my first issue: the home region (i.e. the one my character would initially appear in) was down, so it wouldn’t let me log in. “No problem” i though, “i’ll just choose another home region”. Naturally though, it took me a few goes at randomly picking a region from the long long list which actually worked (from what i could tell there was no way of telling if any of the regions listed were available, which pretty much sucked).
After finally managing to login, i was very disappointed. Pretty much all i could do was walk about and chat, although even then it was very buggy. The majority of features which made Second Life remotely cool simply did not work. And to top it all off i only found 1 other person in the simulation, who seemed to be stuck and showed no signed of life whatsoever.
I have a feeling though that if OpenSim improves drastically that free services like DeepGrid will provide a useful playground for NASA-esque simulations, as opposed to just relying on Linden Lab’s servers.
Finally…
I think that large distributed virtual simulators such as Second Life are very interesting from a development perspective. For example, it would be insanely easy to meet up as a group in the virtual world and collaboratively brainstorm solutions for real-world problems. For physical aspects, you could use the built in building tools and scripting facilities to approximate results.
Of course, it could be argued that you would be better just meeting up in reality - however doing so becomes increasingly difficult and costly when your team might be spread right across the world.
With regard to OpenSim, i hope it becomes ever more usable. Who knows, maybe in the future we’ll have GNU Life? :)
Just over 3 months ago, the developer of a a nifty little open source project management tool called ActiveCollab decided to go commercial and more or less drop the open source version. This didn’t sound too bad at the time, but as i got thinking i realised that there was a definite lack of simple project management tools which were open source. Most of those i found had clunky interfaces or a questionable development status. And of course, more or less all of them are written in PHP, not my most favourite programming language to say the least.
In the end, i was left with uncertainty of the future of ActiveCollab, so i decided to hit two bird’s with one stone and fork my own version of ActiveCollab, but this time rewrite it in Ruby using the Ruby on Rails framework with a goal of making it open source. This seemed like a good idea at the time, as:
I didn’t like PHP
I was a bit of a novice at programming in Ruby
My experience of dealing with the Ruby on Rails framework was sketchy to say the least
ActiveCollab’s PHP framework was similar to Ruby on Rails
Open source is great, lots of people will be interested in working on it with me
The development process started as thus:
I started off with a run-of-the-mill started Ruby on Rails framework project
I ported ActiveCollab’s DB Schema over into the schema.rb
Using the PHP code and the schema as reference, i’d make basic Model’s for each type of object used.
I’d decide to implement a controller
Using the original php code as a reference, i’d replicate the controller and its action’s in the Ruby on Rails project
I’d also import the associated templates from ActiveCollab and convert them into .rhtml files, which are essentially the same except they use Ruby as the scripting language instead of PHP
Whilst trying to replicate the functionality of the controller, i’d also tweak up the related Model to fill in the gaps of missing functionality
In addition, when i encountered anything missing from the Ruby on Rails framework that was required, i’d find a relevant ‘plugin’ and import it into the project, or just implement it all by myself
I repeated steps 4-8 until i the majority of the functionality was implemented
At first, it started out as a little pet project as mine. Though after a while, i grew a bit tired of developing it (developing in this way became very tedious and boring), and decided to push on with the open source aspect of the project and ask the ActiveCollab community if they were interested in my code. The answer i got back was yes.
And thus i decided to open it up fully to the wonderful world of open source development and placed it on RubyForge. I also decided to give it a cool name, RailsCollab.
Initially when i placed it on RubyForge i was contacted by someone who was interested in assisting. So naturally, i added them to the project. I also added another person, purported to be a friend of theirs that was also interested.
Sadly though a month down the line, i received no signs of life from either of them. Its as if they thought “wow great, an open source project. lets join in!” and then promptly died from the excitement. Or maybe they just couldn’t be bothered, i don’t know.
So in the end being the kind person i am, i essentially did all the work myself out of the sheer hope that someone else might be interested in genuinely assisting with development. Or failing that, maybe someone would try it out and provide some much needed feedback.
Sadly though, neither happened even though it was apparent at the start that people were interested.
Right now, RailsCollab is usable as an alternative to ActiveCollab 0.7.1, with the exception of a few missing features which i have simply not got round to implementing yet. And of course it suffers from a few bugs and performance issues here and there. Still, for what it is, it works.
Will i ever do such a stupid thing like this again? I can conclusively say…. hell, no!
After reading Mechanic #031 on the Three Hundred game ideas blog, i got thinking. Specifically, i asked myself “How easy would it be to write a web-based tool for encoding and decoding data to 2d images as pixels?”.
Luckily, this mechanism has been implemented before. The simplest example would be a barcode. However, i wanted something a bit more advanced in order to pack as much data as possible into the image, as i would imagine quite a bit of information would have to be present in each “game image”. After much scouring the web, i found two promising solutions: QRCode and Semacode. Sadly though, Semacode appeared to have pretty dodgy licensing, so i decided to steer clear of it and see what i could make of QRcode.
QRCode was interesting, as in it was very easy to find an encoder, such as libqrencode. Unfortunately, it was very difficult finding a decoder that didn’t just run on a mobile phone (which seems to be a popular way of decoding QRCode’s). The only standalone library that could decode was written in java, oddly enough also called qrcode.
To be honest, i’m a bit put off of proceeding any further trying to get this question answered, mainly because everything seems to be written in Java, – which is fair enough, but considering my skills in programming Java are minimal, i might end up with a rather dodgy botched together solution.
Regardless, i think the concept of deciphering data from 2d images is neat. I’ll just have to find the elusive c-based decoder for QCode, or perhaps even better, find a better supported alternative system.
Years ago, in the good ol’ days of DOS, i remember playing this rather addictive arcade-style vertical shooter called Tyrian. Sadly, i never grabbed a copy of the full version, instead playing through the shareware version numerous times. It was very re-playable, considering you could upgrade your little ship with various power sources, shields, and weapons.
Unfortunately, Tyrian only runs on DOS (although i recall there was a Windows version too), which pretty much leaves me in the dark as i currently use a mac. Of course i could just run it in DOSBox, but it tends to be a bit choppy which pretty much spoils the whole experience.
Luckily, i recently came across OpenTyrian. As the name suggests it is an Open Source version of Tyrian, more specifically a port of the original code (written in Pascal) to bog standard C. In addition, it runs on top of SDL, meaning it should be easy to port and run anywhere… including my mac!
Sadly, OpenTyrian is still under development. Regardless, I decided to try it out and see how much of it works. After making a new XCode project, putting in the OpenTyrian sources, and hitting build i ended up with a cool looking OpenTyrian.app file.
Rather than leave it to your imagination as to what happened when i ran it, i made a rather quick video run-through of it:
Safe to say, its not production-ready yet (its doesn’t even get to the title screen on my PPC mac). Still, it looks very promising and i really hope the developers can churn out a more stable working release soon.
Quite a while ago when i embarked on the Javascript Bandwagon, one of the first things i implemented was a rather simple draw test which plotted a few rectangles and other primitives on a WhatWG canvas object.
One of the little problems i encountered with the WhatWG canvas was that you really needed to play around with the values for the control points on such things as arc’s and bezier curves in order to get the result you wanted. Either that, or draw everything in a vector based drawing tool and convert it to the appropriate set of drawing commands to feed into the canvas object.
Safe to say, i wasn’t so easily defeated by this little problem, and so i had a crazy idea: would it be possible to create a drawing tool written entirely in javascript which used the canvas object?
The first implementation of the JavaScript drawing tool (which i will now refer to as JSDT) resembled frankenstein on steroids. I didn’t completely understand how JavaScript’s “classes” worked, so it was more or less a bunch of hap-hazardly designed functions all placed in the global namespace. Whilst it worked, it was hell to maintain, plus it lacked crucial features such as the ability to rotate and scale objects – as well as group them hierarchically.
For reference, here is a copy of the first version for you to laugh at. Note though that everything (including the manipulators) is handled in the little WhatWG canvas – no DOM in sight!
For the second version i decided to use classes from the ground-up, and make use of one of the various javascript toolkit’s available. In the end i chose Mootools, on account of it being lightweight and seemingly faster than the other framework’s i tried. I also planned out the design from the beginning, which helped a lot.
The second version sadly ended up being the third, as half-way through i realized that i wasn’t using the mootools “Class” object correctly. In error, i assumed attaching function’s to Classes was a bit of a memory intensive operation, and thus i decided to eliminate functions from the JSDT’s canvas objects, and instead place them in an “ObjectHelper” class.
Soon after, i realized how stupid i was, considering the functions are actually assigned to the object’s prototype – not its instance – and thus would be shared between each instance of the class.
And thus, “ObjectHelper” was obliterated. A good thing too, as i noticed a big speed boost! I guess it just goes to show how much slower it is to use “this.object_helper.do_that(object);” rather than the more concise “object.do_that();”.
For reference, here is a copy of the third version. Its much improved over the first, and you can even change the selected object’s style properties via the nice toolbox. Sadly, i haven’t yet got round to implementing the “Save” and “Load” functions, which would be the next major step in implementing the JSDT – shouldn’t be too hard to write out the canvas object list as JSON and send it to / from the server.
Safe to say, i learned a lot about the peculiarities of JavaScript when making the various iterations of the JSDT. I also experienced first hand how utterly annoying it is to have code work perfectly in one browser, yet fail miserably in the other.
One interesting issue i did find with regard to the WhatWG canvas was that Apple’s Safari browser couldn’t quite handle this code:
In Firefox, Mozilla, and Opera this would draw a little filled in square with a line border. In Safari however, it draws a filled in square without a line border! It seems that Safari completely forgets about the path after you either fill or stroke it, so the only workaround is to just plot the path again, i.e.:
…which as you can imagine is much slower, especially if you are drawing lots of primitives!
For my next rewrite of the JSDT, i think i might look at implementing it in an abstraction layer such as OpenLazlo or the Google Web Toolkit. Hopefully then i will be able to eliminate much of the manual workarounds i have had to hack in, instead leaving it to a nice automated tool.
