If..Else has been redesigned with a 3/2 column switch theme. Amongst other things, the entry page features:
Head over there and give your feedback on what you think.
France appears to be making tentative steps towards repealing the 35 hour week. From an economic perspective, the 35 hour week was an extremely weak decision by the french government. Largely pushed on via the powerful french unions, it was based on the lump of labor fallacy fallacy in which it was believed that the amount of work is fixed and thus any increase in the amount each worker can produce reduces the number of available jobs.
This was the same argument pushed forward in the 50’s in which automation would lead to mass unemployment and again later, where computers would destroy entire communities. The fallacy is that work is a finite resource, a lump which is shared out so that if one person works, it means someone else isn’t. It fails to realise that labour markets change and adapt according to supply and demand, and through migration of labour and capital (human and financial).
It’s easy to see this in the real world. Britain and the US have had large proportions of their population working in agriculture, fishing and mining, industries which today are barely noticible on the national balance sheet. Typists and typewriters were ubiquitous in the offices of the 50’s and are barely recognisable to the current generation. Far from wreaking havoc on the country via large scale unemployment however, the economy has in fact grown. New types of jobs have been created and existing industries strengthened by the increases in productivity. Demand absorbs and recreates demand. The act of employment is not a zero sum game.
In France, the results of the 35 hour week have been fairly miserable. Economic growth has been depressed and the unemployment is at around 10%. Government subsidies were also initiated to bail out companies affected by the higher labour costs. The higher cost of labour has also lead to companies reducing/freezing pay rises as well as increase the amount of outsourcing and use of labour saving machinery. Undoing the damage is going to require bold decisions.
That said, the 35 hour week has not been all doom and gloom. Leisure pursuits have soared as a result of the increase in free time. Blacksmithing as an industry is even reviving as more people are taking up horse-riding. Parents now have more times to spend with their family. Hence, whilst from an economic perspective, it may have been a poor decision, it’s a much more debatable issue from a sociological viewpoint.
It does remain to be seen if financial sense will prevail against the powerful unions and sway the french public. Inertia and attachment may yet prove hard to dislodge.
There was a question on the JoS forum about the use and viability of SQL Hints. SQL hints are pretty much what the name implies. They are guides inserted by the developer that provide additional direction to the database on how to execute a particular SQL query. One of the big fallacies of SQL that is pushed across to students is that SQL code is portable between DB, so that what you write for one system can be easily ported to another. Whilst theoretically true in the white glove teachings of academia, in practice the reality is far different.
In the real world, each DBMS has its own quirks, limitations, features and best practices. The situation is analogous to what occurs with browser support of web technologies, only on a scale a million times removed but I’ll talk about this another time.
The other fallacy closely connected to this is that SQL allows us to concentrate on the high level logic and not worry about how a particular DBMS is operating under the hood. A quick chat to any experienced DB practitioner will quickly divest the innocent inquisitor of their naivety.
This brings us on to SQL hints. The general consensus amongst the respondents to the JoS question is that, though hints should not be used at all in a production environment, the DB does at times seem to make some whacky decisions.
Let’s think about what is going on and why. Firstly, SQL hints are similar to training whips. They say to the DBMS “You better do exactly as I say!”. And so the DB does, and for the early lifetime of the application, all is well. However, later on, the situation has changed. The amount of data to search has changed and the DB is thinking, with a bit of independence, “Hmmm, maybe this isn’t the best way as it’s going to take more time”. However, it realises that it’s been given an order and like a slave to an inflexible master, it does as it was told.
The problem with SQL hints is that they operate independently of local knowledge. As long as everything is as it was when the hint was added, things are rosy but as soon as any thing changes, they can force the DB into working along an inefficient execution plan.
Most DB in production operate using some sort of analysis based on the data set and tools available to dictate the course of action. Unfortunately, they can’t analyse the whole data set at execution time (as if it has done that, then it might as well just return the results) and so they analyse “statistics” data that provide a reflection of the full dataset.
This is usually the cause of the problems which lead developers to use hints in the first place. If the statistics are stale, and no longer reflect what is actually in the system, then any analysis based on these statistics will be flawed.
However, with that said, there are often situations in which the developer can be fairly confident that they can beat the DB because they have knowledge of the requirements behind the query.
For example, in Oracle, if you want to get rows N to M of a particular result set, you would generally do something like
Select * from (select a.*, ROWNUM rnumFrom ([result set]) aWhere rownum <= :M)And rnum >= :NIn this scenario, the following query would perhaps be better:
Select * from (select /*+ FIRST_ROWS */ a.*, ROWNUM rnumFrom ([result set]) aWhere rownum <= :M) And rnum >= :NThe reason we can be assured that this is better is that the situation in which something like this would likely be deployed is for paginated reports. We are want the information for the pages as early as possible so that we can pass them to the user as soon as possible.
However, my thoughts are that it is better to use hints sparingly. Often, it’ll be better to re-examine what and why you are doing a particular piece of logic before trying to get the DB to run that logic as you think is suitable.
As mentioned on previous posts, I’m using Wordpress as the backend to this site. The perennial lack of posts on this site may mean that this site may not be instantly identifiable as a weblog but I can’t fault WP in any ways for that. This weekend, I decided to make the decision to try out the latest Wordpress release, version 1.5. Though not officially released yet, the improvements to the application is already enough for me to fully migrate both this site and If…Else.
What are my favourite improvements?
Probably the single most significant improvement. Before WP 1.5, I’d used my own approach for segregating the components of a page into header, body and footer elements via include_once directives. However, the new system provides a unified and standardised approach to what I had been doing adhoc. Finally, we have a mechanism for developing, bundling and deploying the presentational view of sites. I’ve liked this feature so much that I spent 30 minutes rewriting my site design as a theme.
This is another major change and one that has been eagerly awaited. Whilst WP is pitched as a blogging app (a role that it fulfills very well), there are often instances in which we need to publish content that does not fit neatly in the month/day/topic hierachy. For example, colophons , archives , code libraries, faqs are all types of content that would now be accommodated by WP Pages.
What Pages (plural) provide is the functionality to publish single entry content. What makes this feature particularly useful is that you can tie it in with the themes support and provide a maintainable, uniform look and feel. Even better, you are not constrained by this and should you wish, you can override this implicit linking to the themes and provide a custom per-page look. An example of this is my about page, in which I’ve chosen to retain the header and footer but remove the google ads/comments area that is usually found on the blog posts. A small note about this feature: The front-end for the custom pages isn’t entirely finished (which is understandable considering that this is still in testing). To use a custom template for a page, you need to add a custom tag called _wp_page_template and provide the name of the template that you wish to use.
The UI to Wordpress is generally a lot more polished than before. The main entry point is now the dashboard, which provides amongst other things, recent posts and comments. The categories are generally clearer with Manage and Presentation providing the entry points to the areas to manage posts & comments and the look & feel areas respectively. It’s not perfect and work still needs to be done but it’s getting there.
As always, couldn’t be easier. <5 minute including the upload time. There is one thing that you should do when you make the decision to upgrade. Upload WP to a new directory, configure and then rename the old & new WP directories.
Generally, I’m hugely impressed with Wordpress. Matt and the rest of the WP team should be congratulated for their work in bringing what is a premier publishing application to the public.
Eric’s recent post regarding the savings in moving to a standards driven design contains a great paragraph:
What they will see, though, is a faster site. Okay, actually, that’s what their users will see, but that’s the entire point. Suppose I said I could sell you a product that would make your Web site twice as fast as it is today. How much would that be worth? Maybe not much for a fandom site, but even for a small business trying to sell its products online and distinguish itself from competitors, a 2x speed booster would probably be worth buying.
It’s worth stating this again. Whilst we can point to improved flexibility, maintainability and development costs, these are really developer benefits. When presented with a solution, the client generally doesn’t care what was used or how the solution was achieved as long as the product met their needs. When we go out to buy a fridge, we generally aren’t interested in the mechanics of the system, regardless of how architecturally clean or well designed it is. However, we do care about the fridge having lower running costs, operating frost-free and fitting in our kitchen.
Similarly, the client can instantly grasp the significance of some of the other benefits of semantic HTML/XHTML:
Whenever someone pays for a service, whether it is a fridge or a website, they are looking for a product which satisfies some need or deficit; that is they are seeking to gain an increase in utility. The important thing to realise is that the needs of the customer is different from that of the developer. It is only by correctly identifying what the client wants that you can begin to provide a solution.
Just a short update post. I’ve updated my about page to fit in line with the redesign.
In the past, I have never really had much of a focus or a plan for this site. FullyIndependent was really little more than an aside, a chance for me to play around with web development. For example, the CMS that I wrote from scratch for the old site was more a proof of concept than anything else. At that time, Wordpress didn’t exist which gave me a chance to design and develop a CMS from the ground up. In many ways, I was quite fortunate as it gave me an ideal opportunity to explore web development on a LAMP platform.
Developing such a system from the ground up gave me experience in thinking about the underlying design of such a site. I wrote code to handle the templating so as to seperate content from function and code to parse and output xml. I wrote the code to handle to interact with the DB as well as code to validate and parse input/output for security. I also developed a functional frontend to handle the posting and maintainance of the site.
However, in terms of actual content for readers, there was a very noticable lack of updates which ultimately stemmed from a lack of focus. I wasn’t really sure which direction I was going to push the site and in the end, the quantity and quality of the content suffered as it became little more than a sporadic series of ‘look at this link’ posts. To which end, I’ve decided that this time round will be different. Updates are likely to still be fairly sporadic but the overall quality of the posts should be better. There’ll be less random link posts as hopefully, my pseudo-linkblog, if..else, should handle that avenue. Instead, the content here will be focused more on longer entries of a technical bias.
Whether this comes to pass, of course, remains to be seen but fingers crossed:-)