The client PXE boots properly, auto starts Apache, X and Firefox, but Firefox won’t work. 

Problem: Firefox needs to lock on various sqlite databases it keeps in /userhome/.mozilla/firefox and as that fs was actually a nfs export, it couldn’t. 

Solution: md fs mounted on /userhome/.mozilla + untar the content of that directory after system boots.

Imagine you are a carpenter. Most of your job will be sawing off pieces of wood, drilling holes and the likes. Non mind stretching tasks. Of course you can chat while you saw. Now you have to join 3 pieces of wood together. What do you do? Keep talking and somehow join them? No, you stop blabbering and think how are you going to do that. 

How about a mathematician? Does he chat with anyone while he solves a math problem? Try disturbing him and he will send you straight to hell. How about an artist? Will you interrupt one while he is creating a new piece? No, because he will kick your behind while sending you to hell. What about speaking with a mathematician while he sharpens his pencil, or with a painter while he prepares a new canvas, or with a musician while he plays a well reversed piece? You might be astonished to learn that he can talk (I don’t know about flying thoug…) and that’s because, this task is not mentally challenging as solving a math problem, painting something new or creating a new piece of music. A programmer is supposed to solve a problem, compose a new piece of music or paint a new picture for most of the work day. We don’t have as many repetitive tasks as other professions and along with the sheer difficulty of writing there is little brain power remaining to be allocated on chatting or paying attention to blabber. 

Do an experiment: go to Wikipedia, search for whatever comes to your mind at that moment and read the page. Then write on paper (or type) 3 paragraphs about what you just read while you tell two jokes. See if you can do it.

Why did these template engines appeared anyway? Because, back in the dark ages of web development, a little after the prehistoric time (cgi and stuff), there was this bad practice that poisonned developers life: spaggeti code.

...
 
[server side code to connect to the database]
 
Page title
 
[server side code to query the db and get some results]
display those results 
 
[server side code to get some other results]
display these other results
 
etc

If you want to see some real world examples, get phpNuke or an older phpBB. There must be some fossils somewhere on the intertubes. 

So, what did the scientists do?

They started by adding some sistematization to the scripts, like doing the whole data retrieve on top of the script and the output to the bottom. You could tell the designer: “Dude, don’t touch anything from here to here or I’ll kill you, infidel!” and that worked. 

Then, because this wasn’t enough, the mighty scientists invented THE TEMPLATE ENGINES.

They did this to allow the developer to separate application logic from the data presentation. To be honest, I never felt that anyone is forcing me to mix them up and my application logic code was nicely up there in the top of the script, while the html part was way down there on the bottom. I usualy also had a comment line in between, the “don’t touch this part or I’ll kill you” part. 

The scientists also believed that by introducing a new language, the template language, the designers could work on your script too. The reason why Smarty gained so much more popularity over patTemplates, apart the fact Smarty was/is developed by the php.net guys,  was a Dreamweaver plugin that allowed users to do a bunch of stuff to the Smarty tags. For the younger generation, Dreamweaver was the abomination tool of choice for the 2000 and something era web designers to convert the psd/png images to html files (for the ones that actually did that…) But, I never found a designer that couldn’t grasp the simple PHP skills needed to do the display tasks, but was able to learn a template engine language. May my coffee be sour if I lie to you!

Yet another feature that was advertised by some template engines, was caching. Most people, managers, developers, designers, missunderstood this and the myth, that by using a template engine your application became faster, was born. Actually, the engine was marely caching its own operations so your scripts were exactly as fast as they were before you started using the template engine. If they didn’t suddenly became slower.

The only real benefits the template engines introduced were a forced organisation of the code and, in some rare cases, a way for the designer to mess with the scripts and stop bothering you.

Fast forward a couple of 3 years and now, the new toy for the web developers are the frameworks. The biggest benefit they introduced was code separation by task (this part is in bold because this is what Jeff Atwood does and the link is there for the same reason). As most of the frameworks implement a variation of the MVC pattern, you already have specific places where to write specific code: put the data code in the model, the bussiness part in the controller and the display in the view. Unless you have a special ability to do things wrong, there is no way to write spagetti code in this setup. So, the biggest benefit of the template engines is no longer needed. 

However, now you are in danger of producing tag soup. Your web cooking abillities are dimished, from the delicious spagetti to the dull soup. And the web scientists considered now is the proper time to tell the designer to “keep your fingers out of my soup” and invented the code generating code. Very usefull thing if you write autogenerating forms. At least you don’t have to learn another language.

Lawsuit material interlude

First candidate is Jeff Atwood. He pokes template engines because they tend to get complicated.

[...] but you can see where templating naturally tends toward a frantic, unreadable mish-mash of code and template — Web Development as Tag Soup. If your HTML templates can’t be kept simple, they’re not a heck of a lot better than the procedural string building code they’re replacing. And this is not an easy thing to stay on top of, in my experience. The daily grind of struggling to keep the templates from devolving into tag soup starts to feel every bit as grotty as all that nasty string work we were theoretically replacing.

Dear Jeff, I suppose you are familiar with an ancient programming concept, called functions. You know, you get a bunch of code, give it a name and replace all instances of that code with the name. Your code will look cleaner and it will be easy to maintain. Most “non sucky” template engines have something similar to functions, the sub-templates. Using the same principle, you can split your huge, unmaintainable and messy template and it will became smaller and easier to maintain. I am a genius!

Next on list is Aaron Oliver: 

By keeping markup very far away from business logic, the core logic is more stable and there’s less temptation to mingle concerns.

You think your template code is better than Jeff’s mixed code? How is mixing VB with HTML worse than mixing Template Language code with HTML? They are both examples of mixing code with markup. There is no difference between a bad tag soup and a cocktail of VB and HTML, with JavaScript on top for flavour! 

As a conclusion, you both are terrible wrong. There is nothing inherently wrong about any of the solutions, apart the guy that is criticising. Both complain the other solution is ugly, unmaintainable and a pain in the ass. But they are like that because of your own inability to do better. It’s like saying you drive too fast because the gas pedal is easy to push.

Enough fun, let’s go back to serious stuff, young padawan

The problem at hand is easy to describe: get some data from somewhere and display it to the user. 

What are the solutions for this? Answers below.

1) Plain scripts

1) Get and prepare the input parameters (from POST, GET etc).
2) Fetch the data.
3) Prepare the data for output.
4) Output all the html, mixing code and markup.

This is the one and only real solution to the problem, all others are based on this and are just ways to accomplish the same thing easier. 

Use this everywhere, if you can master it.

 
2) Framework with no templates for output

Same as above, but helps you separate the logic parts of the script and reuse the code. It will automatically prepare the input parameters (if the framework is a good one), gives you some premade data fetching code and it is pretty clear where you need to insert the display part, the mix of code and markup. 

This is a smarter alternative to the first solution. However, it adds some overhead.

3) Plain scripts with a template engine

Same as the first solution, but you use a template engine to forcefully separate your main language from the markup. 

Use this if you don’t want the overhead added by a framework and you find that mixing main code with markup it’s worse than mixing template language with the markup. You still get to learn a new mini language. Or you are a lucky guy that knows that smart designer.

4) Framework with a template engine

Separation with even more overhead. 

Use this if the overhead doesn’t bother you and you work with that smart designer.

5) Plain scripts with markup generating code

Instead of writing markup by hand, some generator is used. The code and markup mix is hidden below a layer of functions/objects.

Use this if you don’t require any advanced markup skills. Also, see point 7 below.

6) Framework with markup generating code

OOP at it’s max. However, the generator might not be perfect and some complicated workarounds might be needed.

Use this if you like all the benefits of a framework, are not bothered with the limitations and you have doubts about your markup skills. 

7) Plain script/framework with ajax

Instead of doing all the work on the server side, the display is delegated to the browser. The browser is already re-parsing your output to render it on the screen. You send data in a format the browser will understand (XML or Json), with no display indicators and the browser will display it as it sees fit. However, no browser can do that by itself and another application needs to be build, that will instruct the browser on how to display your data. While each of the logic tasks are now completly separated, the web server might not like it if your biggest bottleneck is the HTTP request itself and not the data fetching or processing.

This is a special case of the solutions 5 and 6. 

Use this if you know exactly how your clients will react and the HTTP request is your main bottleneck: intranet apps. 

Conclusion: as you can see, all solutions are based on 4 simple steps (see the first solution). If you have problems using the first solution, then you will have problems using any other solution. In the end, use whatever you want, but stop bashing other solutions just because you fail to use it properly.

For the regular windows developer, this might seem like a pointless task, because you can write stuff in the registry. I am not the regular windows developer and I’d rather keep away from the registry. And, I want to have the same format for the config files, both on Windows and on the other platforms (Linux or FreeBSD). 

There are some differences where a good programmer would store the config files. For windows, this should look like:

X:\Documents and Settings\%username%\Application Data\myapp\

and on Linux or FreeBSD, it should look like:

/home/%username%/.myapp/

Hopefully, wxWidgets provides as with a function to get the home directory for an user,

wxFileName::GetHomeDir

However, we still have a problem. On Windows, that function will return 

X:\Documents and Settings\%username%\

while on Linux/FreeBSD it will return

/home/%username%/

As you can see, the Linux/FreeBSD output is enough for my task, I can append .appname and I have the path to the directory where I can write my stuff.
On windows, what I get from this function is not enough. I still need to append “Application Data”, which on Windows installs with a different language than English, is translated too.

Msdn suggests using SHGetFolderPath with CSIDL_APPDATA parameter to get the full path to the Application Data folder for each user. And this works, from my experience with other windows projects, also for non english installs. 

Some code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

bool CApplicationSettings::GetConfigDirectory(wxString &confdir)
{
	bool bRet = false;
	bRet = CApplicationSettings::GetApplicationDataPath(confdir);
	if (bRet)
	{
                if (confdir.Length() == 0) {
		     confdir = wxFileName::GetHomeDir();
                }
                confdir.append(wxFileName::GetPathSeparator());
	        confdir.append(wxT(".cmt"));
            	confdir.append(wxFileName::GetPathSeparator());
	}
	return bRet;
}
 
bool CApplicationSettings::GetApplicationDataPath(wxString &path)
{
	// _WIN64 is for 64 bit only, _WIN32 is always defined on Windows
	bool bRet = true;
        path = wxT("");
#ifdef _WIN32
	TCHAR szPath[MAX_PATH];
	BOOL ret = SHGetFolderPath(NULL,CSIDL_APPDATA , NULL, 0, szPath );
	// add checks
        if (!ret)
        {
              return false;
        }
	path.append(szPath);
#endif
	return bRet;
}

If the code runs on Linux/FreeBSD, GetApplicationDataPath will return true and the path will be empty. So, go on and use wxWidgets function to get the home dir, attach .cmt and return true.
If the code runs on Windows and there are any problems getting the App Data dir, the function will return false. If the function correctly got the App Data dir, we attach .cmt and return true.

Someone suggested to read the enviroment variables %APPDATA% for Windows and $HOME for Linux/FreeBSD. This solution seems simpler to implement and if I get enough time, I will research it to see if there are any drawbacks.

However, as this functionality is internal to the CApplicationSettings class, its users won’t be affected by a change at a latter time.

While I agree with the first two statements, I totally disagree with the last one. And this interlude should clarify that.

Before I go on with my rant, I want to explain a bit the philosophy I use when dealing with OOP: you always have to work with consumers and providers. 

The consumer is the user of your class or class hierarchy. The consumer doesn’t care how your class does its job, but only that your class does it, when it does it or why it doesn’t. 

The provider is your class or class hierarchy. Think about it as a mini library, the user of your library doesn’t care how you do your job as long as you do it.

In CTM I have a base class that describes the Cable Modem abstract type. All other objects from my project will have to work with this abstract type and are only interested in the modem status, synchronized or not and they don’t care how the object gets that status. My consumers won’t even care about the cable modem type, they just need a text that describes the modem so they can show that to the user. So, my CModemDetailsBase describes the abstract type my application works with.

In the future I plan to add more modem types to my application. So, I wrote a second class, CWebstarModem, that inherits from CModemDetailsBase class and contains the specific logic for this kind of modem. However, my consumers won’t care if they use a Webstar modem or any other type of modem as long as they can simply ask the modem object about it’s status. I added new functionality to a base class, but internal only. 

I agree with the second statement from my first paragraph, but I’m not always using inheritance: I use it only and just only I want my extended class to be used as my base class. If I get no benefit from inheritance, I’m not using it. Examples below.

Good way: in my project, so far, I have a CModemDetailsBase and a CWebstarModem that inherits from the base class. Later, I will add a CSNMPModem and a CHTTPModem, first dealing with modems that allow you to query them through SNMP and the second with modems, like my current modem, that let you get the status through HTTP. This way, I will have to write the connection code for each type of modem just once. I still have my original functionality in place, allow the consumers to threat my objects in the same way and properly reuse code. 

Bad way: let’s suppose you want to add checking functionality to your form fields. You want a simple method to have the fields in the form checked for proper values. One solution would be to extend the form fields classes, text box, checkbox, radio buttons etc and add the checking functionality. Not such a good idea, because now you will have to extend all types of form fields. Not to mention you will mix GUI code to controller code. 

A better way to solve this problem would be to build a new type of object, CFormField, which will have a GUI member, the textbox, the checkbox, etc and a checking member, which will deal only with the value checking. Now, you can build a class hierarchy that deals only with checking values, instead of building a class hierarchy that deals with all kinds of mixes, CEmailTextbox, CNameTextbox, CNameSelect etc. Also, you can re-use the checkers in other places, outside of a form, let’s say to check if values coming from a web service are valid.

The second example has a third solution, which illustrates the third statement from the first paragraph, the one I disagree with. You could build a new class, that inherits from both GUI element and checking element. Now, you have an object, that is in the same time a GUI element and a checking element. This implies you already have the checking classes hierarchy and it assumes you will build all the mixes you need, like in the second example. Complexity of your code will go up, it will be harder to debug and what not.

In the end, here are some thumb rules for working with OOP:

1. Never aggregate problems. Have a class solve one problem. If the problem can be split, use as many classes as sub problems you have. Detach the sub problem details from the main problem as much as possible. For this, never inherit from more than one base class.
2. Hide as much as you can. Keep the implementation details hidden from the consumer. Show them only what they need to see. This way, you keep your objects as decoupled as possible and make code re usability easier.
3. Keep the choices at a minimum. Your consumers should focus on solving their own problem, instead of trying to figure out how to use your provider.

This post will also server as some sort of index, for every other post related to the project. 

There are no rules, no 40 hours work week, no only open source libs, nothing. Only what I believe it’s best for the task at hand.

The application I chose is Cable Modem Tester, or CMT. I want to build this app because it shouldn’t require lots of coding and it will actually be useful to me: my ISP has some problems with the signal and the modem desyncs itself exactly when you expect it less. This way, when my connection is down, I will know from start if the problem is with my router or the ISP (not that I had any problems with the router from the moment I set it up, back in the days when FreeBSD 6.0 was a rc).

Other articles:

initial requirements and design

utils

First article: initial requirements and design

I want a CLI application, that will get as parameters the cable modem url and a refresh time. It will print the status of the cable modem (syncronised or not). The only reliable way to get this data from the cable modem that I know of at this point is through the web interface. Some isp’s like my own, will block access to other ways to check the modem.

Interlude: How to use OOP

Because there are many types of cable modems used, I want an object that will gather the required data by itself and have a way to present that data to a consumer. So, my object should know about:

1. initialisation, with the cable modem type (maybe also the url and port) and refresh time.
2. a start method, that will put the object in “data retrieve” mode.
3. a stop method, that will change the “data retrieve” mode to a “stop mode”.
4. cleanup, to allow the object to clean the mess.
5. get the syncronisation status, to allow a consumer to get the connection state.

My object should automaticaly gather the data it needs, after put in “data retrieve” mode. Thus, it will need to start a thread and do the http transfer and file processing in that thread. An user of this object should only care to start, stop and ask the object for the data.

I will be using cUrl library to perform the http requests. Probably, I will also use wxWidgets for the portable threads and later for the GUI.

Preparation:

- set up a Visual Studio Solution

- set up the project to use curl

- set up the project to use wxWidgets

Most people work just to get in a paycheck and not because they like their work or care to do a better job. For them, if your company sold last month just enough to pay for everything, it’s enough. No need to improve, no need to change. For them, work is just a necessarily evil, not a way to accomplish something. Their “work” is being in the office for 8 hours and the actual work they do is just an afterthought. These are the people that want to be promoted because of the perks of the higher position and not because they feel they can do a better job. These are the people that expect automatic promotion or rises after a set amount of time. You know these people exist, but everywhere you look, on the Internet, on TV, you see only the guys that did exactly the opposite of them and you might be tempted to believe the “regular” guys are a minority. This is not true because there is nothing one can write about them, thus there is nothing you can read about them either. Keep this in mind, while your primary goal at the company you work for is to improve your work, the others just want their paycheck and go home with it.

While there are some people that can properly work from home, most can’t. And it’s not because you can’t communicate face to face with your coworkers, but most of us can’t focus properly when at home. You need a great deal of self discipline to work from home. There are plenty of distractions, from TV to kids, pets and daily home routine (do the dishes, cook, get out the garbage, do the laundry etc). Also, some of us are pretty much lost if there is no senior to tell them what to do. Also, most people won’t find something rewarding and fun in the work they do, but in the things they do while “at work”: speak with coworkers during lunch breaks, the usual chit-chat from the office, the stuff they are used to see as fun from the school days. And you can’t do all that if you are at home.

There are two reasons why you are not allowed to work from home.

The first reason is the impact of you working from home will have on the “regular” workers. They will fail, because of the numerous distractions and when being denied to do it again, they will conclude that “working from home” is just a perk, not a way to work. As their only work measurement unit is the amount of time you spend in the office, the manager will end up with a bunch of disgruntled workers and nobody wants that. So, instead of making you as productive as you can get, the manager will try to keep the full team as productive as it can get, even if this means he is wasting you. 

We The Robots: Good Work, part 1

The second reason is the simple fact that today’s managers are yesterday regular workers. They simply can’t imagine there are smart ways to improve productivity and they genuinely believe that the only way to get more work done is to stay more in the office. These guys are the ones that will deny you having a second display, or a better chair, or a better desk. These are the guys that will push 20 people in a small space reasoning that you need space only for a keyboard and a display and the office noise is just something you get to deal with. These are the guys that will try to apply to your problems, solutions from a totally different and irrelevant industry.

We The Robots, Good Work, part 2