Today at work we decided to wait for the next LTS version of Ubuntu, 10.04. Currently we run 7.04 which is no longer receiving updates. For a while now actually. This summer I worked on planning the upgrade process from 7.04 to 7.10, and finally to 8.04. Which is the current LTS version.
I was able to do a dry run upgrade on our backup server. So I was able to document every step of the upgrade process. Ubuntu upgrades nicely and from 7.04 to 8.04 there are only minor changes that need to be done in our configurations. Even the HP iLO software, for which support on Debian based systems is a bit vague, works out of the box with a native driver. No longer do I need to manually compile the HP iLO driver after every kernel update.
Originally we planned on doing the upgrade somewhere this month or December. But due to tight schedules (it’s quite busy for us) January or February seemed be more likely. Since 10.04, the next LTS version with support until April 2015, is out in April 2010 it likely doesn’t hurt to wait a little bit longer. As far as I know every LTS version so far was easily upgradeable to the next LTS version. So I expect upgrading is going to be a breeze. But of course, I’ll be running tests first when 10.04 gets released.
Why not upgrade to 8.04 first and run that first for a couple of months? Well, support for 8.04 ends in 2013, so 10.04 gives us more years of updates. Also, the upgrade process takes (down)time, time to get there, man-hours that need to be paid etc. etc. Further more, without a doubt, with every upgrade there are some issues going to arise. Small and trivial or stuff that brings down every website that’s running on it. Resolving these issues also takes time, which delays the progress of other projects and what not. By skipping yet another version I think we’ll actually save time.
I’m looking forward to it actually. On of the cool things I’m looking forward to is being able to upgrade Zend Framework from 1.8 to 1.9+. I’m also planning to use memcached and perhaps some PHP optimizer to greatly speed up some of the webapplications. And of course, Perl 5.10 (perhaps 5.12 by then?). Although we, unfortunately, don’t use Perl for our websites I like to keep Perl up to date as we use it for several system administration programs. CouchDB also caught my eye :-).
OK, enough for now. Bedtime :-).
So already a week and a half ago I purchased ifsoGUI and only today I finally found (made) some time to experiment with it. I’ve read the examples and they were all very clear, but you don’t actually learn anything without experiencing it first hand. The API of ifsoGUI very much resembles that of MaxGUI so it’s very straightforward. With the only exception that besides using an event queue you can also use callbacks for every gadget. These callbacks get executed as soon as an event gets fired for the gadget. Powerful stuff.
Anyway, playing with ifsoGUI inspired me with new game ideas. My mind started to do some creative thinking again. Something I haven’t had for a long time. It’s nice to know that’s not gone yet and it’s very neat how an idea can evolve inside your head. Today I finally realized that I should change the genre of games I should try to create, or at least start with. I’ve been mainly focused on airplane/spaceship dogfighting games which is a genre I enjoy playing, but am currently bad at creating. It took me 3 prototypes to realize I’m not cut out yet for this genre. Of which the first two took more time than a prototype should take. For the third prototype I only invested a couple of hours. I realized I was doing the same thing over again and terminated it.
ifsoGUI inspired me to start thinking about a completely different genre. With the ease of creatingÂ panels, buttons, sliders, text boxes and all I started visualizing how easy it would be to create small little windows to manage lots of objects. So in other words, micro-management. I’ve always enjoyed playing Tycoon type games, like Roller Coaster Tycoon, Theme Park and Theme Hospital. I don’t play these game a lot anymore because they consume way too much time. But I’ve spend a lot of hours on it in the past already and it’s a fun genre.
So I suppose I’m changing my direction to set course to a new destination!
I had been looking for a nice library to create in-game graphical user interfaces but couldn’t find any BlitzMax module I liked. I’ve looked at FryGUI in the past but decided not to use it. The examples were impressive enough but I wasn’t under the impression that it’s being actively maintained. CEGUI, wrapped by Brucey, is an impressive module as well. My impression was that skinning is rather hard, as is its ease to use. I also heard it’s not fully wrapped yet, but I might be wrong. I don’t necessarily think this is a bad point as one rarely needs all features. But not being fully wrapped means the API can get some breaking changes as well. And I hate it when that happens (points to Zend Framework).
As both are free modules, which is of course always a good thing (my htbaapub.mod modules are free as well), you’re never certain of support when problems arise. Since it’s all open source I can make any changes I want myself if ever needed. But I’m lazy, I don’t want to do that. I want to focus on creating my game or application. Not being sidetracked because I library I use doesn’t do what it should do. I’m not saying that this is the case for FryGUI or CEGUI (which was recently updated), but it’s something to keep in mind.
Not too long ago a new commercial library was released, ifsoGUI. It had put me off at first because of the skin that was used looking fairly identical to the default Windows XP theme. It gave me the impression that it tried to be a in-game MaxGUI clone. Until I found out it had support for custom skins which are also easy to create.
All the demo’s were impressive enough, the module is well documented (there’s also a Wiki, the other named modules are documented as well by the way), a clear API, the source is available, it’s being actively developed and there’s active support for it. Another reason I chose this module was because of the short learning curve. I need to be able to quickly implement it, not spending hours and hours figuring out how the module is supposed to work. I think ifsoGUI gives me this, and that’s why I chose it.
PS: If I made any mis assumptions please let me know so I can correct my post.
So today at work I started working on a website that’s basically a clone of another one. The website to clone has a rather old code base but a fully working control panel with order processing, payment reminders, CRM and more. As the code base for the website itself was way too old I decided that that part should be newly written. Nothing fancy, just loading a few things from a database and displaying it.
The control panel on the other hand has to stay updated for both websites. Feature wise they should stay similar and bugs found in one of the control panels should be fixed in the other. So why not generalize the control panel and make them identically the same? Well, thinking ahead, the target group of both websites is different so there are always going to be a couple of specific features not needed for the other target group.
Before I’ll tell what I did to make this possible I’ll explain the current setup of the first site (the original website being “cloned”).
The original Git repository contained a directory called admin. I cloned the repository to strip out everything besides the admin directory with git filter-branch. I then added this new repository as a submodule.
The new website is, of course, also a Git repository. Since I need the control panel for this website as well I could add a submodule that points to the original Git repository. But that would severely hinder the process of modifying it for the new website. So instead I cloned the control panel repository. In this clone I maintain a branch for the new website. The new website has a submodule that points to this branch.
The benefits that’s giving me this is that I can make all the modifications I want, commit them to the branch created for this. Any updates that should be applied to the other site as well can be cherry picked to the master branch. When done I let the main repository (the one I filtered out of the original website) pull the changes back.
All in all this might sound a bit complicated, but it isn’t really. Thanks to Git I can keep both control panels up to date and safe without too much worries. Thank you Git!
Last Thursday I’ve made my first purchase over at Amazon and was happily surprised it arrived today. That’s the fastest delivery time I’ve experienced from a webshop not located in my country! So kudos to that.
Game Coding Complete, 3rd edition was what got delivered at my house. I’ve only skimmed through some pages and so far I like what I see. It’s quite a big book with 908 pages so I’m afraid it’s going to take me a while to finish it.
I ordered the book because although I’ve got quite a bit of programming experience, I don’t have much experience in programming games. Sure, I did a couple of small games and prototypes but never gotten much further than that. Since the author, Mike McShaffry, is quite the veteran I thought, why not learn from one of the best?
The book has lots of examples and am eager to start reading it.