New job, new set of priorities

This blog is not dead yet. Only that I've switched jobs and I have a new set of priorities.

Also, I got a new set of hobbies. I've expanded my realm of hobbies into the hardware part of electronics. My dreams and ambitions are no longer confined to software ones. I am officially an arduino board owner since a few days back.

My erlang adventure will continue. I have designed a blog in erlyweb, I will opensores it when the editor for the blog is reasonable usable.

Certain abstract features I'd like to implement before/during the alpha release:

• Support for power users and normal users
• Multi-user blog
  
• Weblog editor mode
• User management mode

I hope to finish it by next year say around January.

Most of of the work will be done on the editor part. The blog 'view' itself was the least hassle to get working.

VM Plan

Okay, that's it. I'm tired of rebooting to get tools I need in 2 seconds notice. I'm getting tired of chasing down working packages and checking for dependencies. I want to cross-compile with the least amount of hassle.

Virtualization, cometh to the rescue!

Plan

1. Use slamd64 as platform for virtualization.
2. Use kvm on top of slamd64.
3. Party!

The implications are: I could run distributions that were built to do certain tasks, instead of spending hours and hours of precious time to build some packages to run some application.

Hm. What to say. C++

I have a love and hate relationship with C++. Especially, when I return for months on end without seeing or modifying any C++ code. I keep committing newbie mistakes like, not initializing default objects on the aggregate, which lead to segfaults. Not catching potential thrown errors, which lead to segfaults once in a while.

Relearning how to read compiler errors, linking errors, I can pick this up reasonably quick. The more I read template error diarrhea, the better I get at it. But linker errors are always bad. They tell you something is wrong. But little clue as to which units are not talking to each other, or maybe the clues are too subtle for me.

My understanding of C++ has always been superficial to say the least. I have always regretted this. But we're learning like always. Maybe not in the pace I demand of myself, but we're getting there.
It's not that my coding and personal development as a coder has been deteriorating or becoming stagnant, it's just that the amount of stuff to learn is overwhelming.

I'm getting there. Error by error.

To build a cms, one must know wtf a cms is

The main obstacle in this project is. I currently have no clue as to what a cms is supposed to look like. I guess I have to go check out different cms spawned under the abomination called php. (php is responsible for the top of the bell curve) Don't get me wrong though, my best friends are users of php. We used to be close. We just lost touch that's all. There are prettier languages out there demanding my attention. Python (which also makes my heart skip a beat) must also have some cmsesss out there. Gotta install that too. Hm. That means I have to also delve into Ruby.

I have never coded anything in ruby. I checked out the syntax. It's horribly simple. I was weaned on C++, templates, etc. (You could do worse though, BASIC, strange enough though, that C++ to this day supports gotos) I wish I was weaned on Ruby first!

The first problem that comes to mind is the following: I have no desire to pollute my production system, with shite I will not use regularly. This means I'll have to buy a pollutable system, or convert another existing system to be a pollutable one, or start mucking around with virtualization. Or simply buy some bandwidth from a 3rd party.

I'm cheap and broke. So the last option is not. I have no spare systems. Except for project X
but more on that later, but that I will not pollute either. Which leaves us virtualization.
My amd 2x core supports virtualization instructions, so hardware-wise there is no big problem. The main problem I think is the lack of good userspace programs for linux kvm and the lot. Actually I don't know enough about this to judge correctly. Or judge which virtualization solution on linux is the best for my case.

More on this later. I shall go and research.

Mental note:
Write about virtualization on linux

Build targets: erlang, yaws, erlyweb

Migrating to another OS, means you have to get, hack, build some apps, to achieve/approximate the same user-experience as the previous OS.

So, my first few build targets for slamd64 were: erlang, yaws, erlyweb.
And some other stuff that are quite handy: valgrind, valkyrie, ddd (dead project).

I had to create some Slackbuilds for erlang and yaws, but erlyweb was the easiest to install.
A Slackbuild in Slackware parlance, means, a script to build a installable archive file, to deploy software on a slackware-ish systems. If anyone wants these Slackbuilds for i386 or x86_64 architectures, just drop a message, and describe a method for me to send you the files.

Installing erlang and yaws, was a bit more elaborate. Luckily, these two support the standard method of building and deploying software i.e. ./configure && make && make install.I always use my tool buildslackbuild to generate slackbuilds, if the standard method is used.
Mental note: Write about buildslackbuild

Erlyweb was easy. All it requires is a symbolic soft link from erlyweb-<version>/ebin to /usr/lib/erlang/lib/erlyweb-<version>

comme ça:

mkdir /usr/lib/erlang/lib/erlyweb-.../
cd /home/user/.../erlyweb-.../ && make
ln -s /home/user/.../erlyweb-.../ebin /usr/lib/erlang/lib/erlyweb-.../

Migrated to another OS: Slamd64

I have a 2x core amd machine. It runs windows xp, slackware, slamd64 and sabayon.

Some free promotion might be in place here, since I have never financially supported the last three OSsss (operating system).

Slackware is the venerable, but highly relevant (to this day) OS based on GNU/Linux. It's a back-to-basics-type of OS. I doubt there is another OS that is more instructive on the workings of UNIX-type (System V) systems (that is based on Linux :).

Thanks Patrick Volkerding.

Note: BSD-people, drop it. I'm not listening.

Slamd64 is the project of Fred Emmot which is based on Slackware, but supporting x86_64 (amd) architectures. Hence the name. It's young, vibrant. And follows the Slackware way of things. Cheers, Fred.

Sabayon, I barely use, but I will once I have more free time on my hands. It's a gentoo-based system, extremely easy to use. All the batteries are included, that means to say many functionalities that require tweaking are already pre-configured, and are ready to go! It supports most of the games available to GNU/Linux. The project is an italian one, geographically, but they have won the hearts and minds of many libre gamers around the world. They support both x86 machines and x86_64 machines.

Ringraziamenti, tutti gli amici! (Thank you babelfish)

So why did I migrate from slackware to slamd64? The main reason is because of my need/greed for speed. I have noticed that apps do react to events, and process tasks much more quickly on slamd64 than slackware. Also, slamd64 retains the freedom for tweakage as slackware does. I have found that migrating my /etc files is easy, since slamd64 follows slackware closely in how the system is laid out.

I shall build my erlang based cms on this platform now. This should have little to no unintended drawbacks to the project, since the erlang code itself does not depend on the architecture/platform where it is built. The erlang-interpreter is a different story though.
Mental note: blog that "different" story

Content management system with erlyweb

Plan

Erlyweb-0.70 has been installed. Now I'm looking forward to building a free/libre content management system (cms), combined with techniques gleaned off from Ext js.

Strategy

Steal users. Make it easy and attractive for them to migrate from their current cms. Favour standards above massive configuration files. Mysql users are fair targets. KISS leads to LOVE. ("Keep it simple stupid", "Leave out virtually everything").
Make easy stuff easy to do, hard stuff possible to do.

Focus on usability. Make the user interface (ui) as intuitive as possible. Make easy stuff, really, really easy. There should be one way to do one task, and that way, should be the most intuitive and shortest way to execute the task.


TODO

• Gather requirements (what makes a cms tick?)
• Plan basic architecture (Security and the whole shebang)
• How does Ext js fit into all of this?
• Design plugin-based extensible system