Posts filed under 'Programming'
Decoupling the User Interface from the underlying code has been one of the holy grails of application development.
Layers of indirection and new patterns have been invented over time to try to separate what the user does from the back-end data. It’s been a long and difficult journey but WPF is the last attempt at completely separating the user interface from the gut of an application, leaving graphic designer do what they do best and programmers do what they do best.
I think this disconnect has actually hindered the adoption of WPF to a great extent.
I also believe that Silverlight, while showing great promises, is going to take a long time to get off the ground.
Good graphic designers who work on User Interfaces are too few and far between, and large organisations will take time to get staff with a sufficient level of expertise to be useful in developing meaningful WPF/Silverlight applications.
Until now, the bulk of the development effort was done by developers. Most ISV only have developers onboard.
As far as I can tell, it seems that main reason behind this slow adoption is that WPF/Silverlight has only been noticed by developers and they don’t know what to make with it.
WPF/Silverlight are not really developer-friendly: the development infrastructure is there but we’re left with a blank canvas and nothing to drag and drop onto it.
There will be a great gap, probably lasting a few years, before there are enough experiments in these new user interfaces that some useful lowest common denominator can be exploited by non-designers.
We’ll have to wait for tool vendors to provide the bulk of user interface blocks and for a few new patterns to appear before all the designer-challenged developers like me can make decent interfaces without requiring a professional graphic designer in their midst.
In the mean time, we’ll probably have useless, but pretty, applications, some useful, but ugly ones and a lot of people scratching their head trying to couple the designers and the developers in a working relationship.
February 10th, 2008
Microsoft SQL Server comes in many editions, ranging from completely free to use and distribute to versions costing tens of thousands of dollars.
For small businesses, or when you can live with the limits imposed, the Express edition is one option to consider.
Here are some reasons why SQL Server Express may be a good choice:
You’re upsizing an Access database
SQL Server is the natural extension of upsizing an existing Access database. It work automagically with minimum effort providing that you followed some simple good-design rules from the start.
You’re future-proofing your needs
Because SQL Server comes in many flavours, you know you -or your customers- can upgrade to a more capable (albeit more expensive) version in the future if needed.
Very flexible
As usual with a lot of Microsoft development tools, SQL Server will happily let you shoot yourself in the foot by providing you with a fairly easy way to treat your database as a complete development platform.
It’s good in the sense that you have interesting tools and capabilities included in the server, and it’s bad for the exact same reasons.
I tend to prefer database servers to be just that: data repositories, and I’m not too fond of relying on specific, non-standard features of a particular database system, but what do I know.
Excellent out-of-the-box development support
Deep integration with .Net and Visual Studio, without any effort, Microsoft saw to that of course.
In some cases, such as LINQ to SQL, it’s almost the only real choice, although the other database vendors are working hard at the necessary providers, so that lead should be short-lived.
There is something to be said about developer productivity: you have to give credit to Microsoft for making their tools well integrated and usable from each-other. What it means is that for small developer shops there is much to gain in surrendering to this “ease of the default”.
Of course, it’s a double-edged sword, but having a complete development infrastructure work out of the box is certainly a big help, and if you don’t like it, you’re still free to chose something else.
Lots of tools
With SQL Server Advanced Services, you also get Server Management and Reporting Services. These are great tools made available for free.
The only missing one for SQL Server is the Reporting designer. While the reporting service means that you can use existing reports, only SQL Server Standard and Enterprise have it.
There is an option for developers though: the (nearly free) SQL Server Developer edition is in fact the same as SQL Server Enterprise, without the license to use in non-developer or tester environment. This means that as a developer, you can create and distribute your reports to be used by your customers who will be using SQL Server Express.
Did I mention it’s free?
All this is free, as in beer, not as in liberty though.
For commercial applications targeted at small businesses, SQL Server Express is a really good choice: you can distribute it without problem, the customer gets all the tools, can easily find outside support, and they can always migrate to a more beefy version if their needs grow, all that without having to depend on you.
So it sort of offers customers a kind of freedom that they wouldn’t have with other choices.
Of course you can get that with other database systems, although you have to be careful which Open Source one you choose: I recently decided not to use MySQL any longer for the simple reason that it’s too expensive and restrictive in a business environment, at least for the kind of work I do.
Why would you not want to use SQL Server Express?
You don’t want to depend on Microsoft
That can be a good reason enough sometimes. There is nothing preventing Microsoft from crippling SQL Server Express in the future to force users to move to a paying version early.
I suppose that whatever database system you use, even Open Source ones, there is always the possibility that the company supporting its development goes bankrupt, the Open Source projects goes dead or decides to go in a direction that doesn’t suit you..
It’s only supported on Microsoft OS
True, and that’s a good reason to chose something else.
There is a hidden cost in SQL Server Express: it needs to run on a Windows machine, and that’s not free, although SQL Server will work on older Windows 2000 machines and Windows XP which are arguably not expensive.
Your database needs will exceed SQL Server Express specifications
If you think any of your databases will grow beyond 4GB or that it will get busy and you need all the RAM and CPU you can get, then SQL Server Express is probably not for you as it will only use 1 CPU and 1GB of RAM at most.
If your needs go beyond that, then you’ll have to move to a paying version.
Upgrading can be expensive
It’s true that moving to the next cheapest upgrade of SQL Server Workgroup will cost you about US$700 for a 5 user license. The limits imposed on the database are much higher (2 processors, 3GB RAM and no size limit) but if you need more clients / or higher limits, then the expense will grow quite fast, and you’ll have to manage those hateful client access licenses.
Your needs are more modest
We haven’t talked here about single-file/single-user database systems.
These databases don’t user resident services and are usually meant for more limited needs, sometimes allowing only a single user to be connected.
The footprint of these non-server databases is a lot smaller, typically only requiring a single dll or a handful of files to be installed.
They are extremely useful for desktop application that do not really require multi-user support or advanced security features.
Here again, Microsoft offers SQL Server Compact, which, despite the name, doesn’t have much to do with the other SQL Server editions. This one is also free, but has a limited feature set and only allow single-user access as it is meant to be a lightweight database and works well in limited memory environments such as those found on mobile devices.
Of course, here again there is a lot of competition: Thunderbird, SQLite, MS Access and VistaDB (for embedding into .Net applications, not free) to name a few.
These are pretty good times when it comes to databases: we get more choices now than we ever had.
As usual, choosing a database as a back-end for your products isn’t easy: you need to consider cost, licensing, support and the future.
There isn’t a single database system that will meet everyone’s needs for all types of use, so choose carefully.
SQL Server Express is a very good contender in that market. It should not be dismissed out of hand because it’s from Microsoft, in the same way that PostgreSQL shouldn’t be dismissed because it’s Open Source.
Just use the tool that best answers your needs for your particular circumstances.
References:
January 30th, 2008
What does 04/05/01 mean to you?
Let’s make it easy: is that date in 2001 or 2004?
And if I write it like 04/05/2001, is it really better? are we in April or May?
And the answer is…
If you are from North America and a handful other countries 04/05/01 would mean 5th of April 2001.
If you’re in Asia or some eastern countries, if could be 1st of May 2004.
For the rest of the world, it would look like 4th of May 2001.
We cannot ignore any longer the importance of writing dates in a format that is understandable by everyone.
Still too often, web sites -even big companies- with a global audience state dates in a format that is probably obvious where they live but not consistently so to everyone else.
Developers are sometimes guilty of this sin, as can be seen in the format chosen to specify dates in Microsoft Access SQL, which requires that hard-coded dates be formatted in the US rather than the more neutral ISO8601 format.
I wonder how many bugs that little egocentric feature caused in business applications that where developed by foreign coders…
I know it also happened to me at least once…
The worst thing is that when you write 04/05/06, you may very well have thought about the rest of the world and meant DD/MM/YY; alas, unless the context grants us some clarification or the actual date is unequivocal, there is sometimes no way for a lot of us to know for sure what you really meant.
We should ban the use of the short date format in communications that may be read by more than 3 people, in today’s world, that’s pretty much all communication.
Instead a simple format such as 05MAY2006 is clear an unequivocal: it’s easy to read and understand, regardless of where you live.
You’re free to add spaces, dashes, dots, comas or slashes to it if you want, you can use 2006MAY05 if you prefer or even MAY05,2006, whatever pleases you: it still remains readable.
The rule is simple:write the year in full and never write the month as a two-digit number, that’s reserved for the day
The point is that you, me and the rest of the world can read it and understand exactly what was meant; it’s an easy problem to solve.
Surely that means something to you?
References
December 15th, 2007
MediaWiki is the wiki software behind WikiPedia.
The issue, when using it as a software development tool, is formatting code in a pretty way.
As we did with WordPress before, here are some details to make dp.SyntaxHighlighter work fairly seamlessly with MediaWiki.
Install the client-side highlighter
Download dp.SyntaxHighlighter.
Uncompress its content under a new /skins/common/SyntaxHighlighter folder in your MediaWiki installation (don’t forget to make sure the files can be read by the web server; for instance, on Linux you may use chown apache.apache -R *).
In the skin template you are using for your MediaWiki site, insert the necessary code as required. In my example, I use the default /skins/MonoBook.php template into which I added the following:
Just before the closing </head> tag:
Just before the closing </body> tag:
Note that you must include a reference to each source file corresponding to the type of programming language you want to highlight.
Have a look under the /skins/common/SyntaxHighlighter/Scripts/ folder to see which languages you can highlight; there are a lot more than the few I use on my site.
Install the WikiMedia extension
I’ve created a small extension to WikiMedia to allow us to enclose any source code in a new <codesyntax> tag.
Click on the View Plain option below and copy-paste the following code into a new file that you will save under /extensions/syntaxhighlighter.php (again, make sure this is readable by the webserver).
Add the following line to the end of your LocalSettings.php file, right before the closing ?> tag.
Usage
To highlight code in your MediaWiki pages, just enclose your source code with the new <codesyntax> tag. This tag takes a lang attribute to specify the options that normally would be listed in the class attribute in the dp.SyntaxHighlighter documentation.
For example:
Will display as:
For more information on using dp.SyntaxHighlighter see:
http://www.dreamprojections.com/syntaxhighlighter/Usage.aspx
February 20th, 2007
LAMP, Zend, .Net, Struts, Ruby on Rails, Catalyst, and a hundred other development platforms all compete for you attention, all pretending to be the only thing you’ll ever need to satisfy your every needs in web or UI development.
Making a decision is really hard: you want the best for your new project and want to make the right decision. In most cases, that means not cursing yourself down the line for a choice that didn’t turn out as expected.
When you start looking into all these platforms you can be blown away by the ease of implementation and elegance of some; your head spins at all the features and claims being made and it becomes hard to achieve a rational decision.
I’ve been faced with that very issue recently and it sucks. Actually, the time spent investigating all these possibilities is really what is being sucked away.
Of course, learning about new technologies is not just fun, it’s also essential: you have to keep on top of what’s new and decide if you want to join in on the fun or just stay comfortably where you are.
I also realized that you need to get away from the coolness factor of each these much touted technologies and actually try to be objective.
During my investigation, I tried to decide what were the really important factors that I should consider to make a rational choice.
I came up with the list of the following 10 questions that I think everyone should ask themselves when choosing a platform for an important project.
1- Is the platform wide enough?
New technologies that can show amazing productivity get all the buzz. After all, that’s what we developer want: enough with the nuts & bolts! Give us a toolbox with all new shinny power tools!
The problem is that often these technologies are impressive, but looking beyond the sample projects into what actual users get confronted to, you start noticing discussion threads that should obviously signal that the platform is not wide enough.
Choosing a technology that hasn’t achieved its goals can be a huge problem down the line: you implement 80% of your project in record time, only to realise that the platform you chose doesn’t support proper cross-browser detection, or that its implementation of security is way too lax, or that it only support XML for data storage and now you actually need a real database for performance reasons…
In those cases, you can of course develop those areas yourself and contribute to the project, but doing so supposes that you planed it all along and you factored that in your schedule, both in time and in cost.
2- Is it popular?
In other words: are other professional people actually using that platform in real life?
I’m not talking about Joe Developer using it for his local community church website. I’m talking about businesses or large organisations actually using that software platform successfully.
If all you need is a simple 3 page website, then professional popularity amongst the Top 500 business companies is probably not that important. On the other hand, if you plan to build a large project, or you know that your project could grow large in the future, then you probably want to ensure that others have taken it there before you.
3- Is it mature?
Has the platform existed for long enough that it went through enough abuse to withstand almost anything you can throw at it?
A technology that is only a couple year old may be too young to have evolved to the point where it actually can solve most common and not-so-common problems. Technology evolves through iterations: each one is a good long hard look at what didn’t work and tries to fix, improve and extend.
A young technology may be more cutting-edge and exciting, but when you need to commit to it for a big project, its age may quickly come as an issue; its shinny surface may blind you to the black holes waiting below…
4- Are local developers available?
Always think about the future. When you’re gone from the project, who is going to look after it?
Getting a web project entirely in Rebol may be cool and fun, but how many people in your city actually use that thing anyway?
Aren’t you creating a liability if you’re dead-set on choosing a platform that cannot be maintained?
5- Is it scalable?
Most projects start small but dream of ending-up big.
It’s usually fine at the beginning when the number of users and visitors is manageable, but what happens when you start to be successful?
After all, that’s why we craft our projects: we want them to succeed, we want the world to see them. When the world starts coming though, will the terrific platform we’ve chosen break at the seams?
How much overhead does the platform create? It is flexible in its database support? Is there a way to implement clustering or persisting sessions accross multiple servers?
What’s the cost in memory and CPU resources? How many simultaneous connections can you get? What are the bottlenecks? What do you need to do to compensate for them? How much would it cost?
6- Do you have control?
Some frameworks work hard for you and can make you really productive. Sometime though, they try too hard and hide too much from you.
When a feature doesn’t exactly work the way you want you have to dig deep into the entrails of the beast to make sense of it and change its behaviour.
A platform that was all nice and pretty can get very dirty and complex inside, making it difficult to adapt to your needs.
A platform should do most of the hard work but still allow you to redefine its default behaviour without much hassle. It should be built with extensibility in mind, making easy thing easy and difficult things possible.
A case in point are 4G development platforms: they usually have a fairly narrow field of expertise and tend to use graphics and nice simple paradigms to quickly build complex tasks but when you are faced with a specific issue that hasn’t been solved by the platform, you often have to resort to ugly hacks to get around their limitations.
7- Does it satisfies the essential constraints for your project?
When being blinded by something cool, we often become skewed in our judgement and guilty of lowering the importance of constraints that are actually critical for our project.
In all honesty, I really wanted to use Ruby on Rail, and I liked the principle and elegance of it so much that I came to seriously consider it, that is, until I came to my senses and looked into something that is critical to my project: support for complex Asian languages.
Ruby is being developed in Japan, so you could think that it should be able to handle complex ideographic characters well.
Turns out that the Japanese are not terribly fond of Unicode and, unless I’m mistaken, prefer to use Code Pages instead. The result is that Ruby doesn’t have great support for Unicode, and that sucks.
That’s why Unicode was created: to attempt to simplify all this patchwork of implementations that are not compatible with each other.
Because I needed to be able to handle English, Mandarin, Cantonese and probably any other language out there, Unicode is the only viable option to abstract the issue of language enough that it becomes manageable.
So because of Ruby’s poor support for Unicode, it would not be rational to use Ruby on Rails for my particular project as it would probably greatly increase the complexity and hacks necessary to manage complex Asian languages in a unified and simple way.
8- Documentation?
All framework have a more or less steep learning curve: you need to think differently to adapt to the particular framework’s frame of mind, so to speak.
Make sure that the framework has a lively community, that it has more documentation than you can swallow and that documentation is well organised.
Make sure also that there are samples, tutorials, webcasts, videos or whatever that cover the principle aspects of it.
A beautiful framework no-one talks about means that no-one will answer when you have a question. A beautiful framework without documentation is useless. A beautiful framework with lots of disorganised docs means that you’re going to waste a lot of time experimenting instead of building your project.
9- Support?
Here I mean support in the wide sense of the word: who is behind the framework. Are they likely to stay in business long after your project has been completed?
Are they commercial or Open Source? In either case there are issues for and against: a commercial venture backed by a small company may falter and disappear overnight. Similarly, an exciting open source project managed by only 2 people can suffer the same fate when they decide to move on.
Support also includes what help is available to you when you encounter issues. Is there any guarantee that you could have your important technical questions answered?
If you encounter a large issue, is there someone to help you?
I would contend that the best and most serious projects should have professional help available: you can always fall back on paying someone to help you through, whether it’s the original developers, a paid-for support hotline or a third-party specialist, it’s important that you know you can get your answers when you’re stuck.
Developing for an important project without safety net is dangerous: you can waste a lot of time and effort, endangering the very project you are undertaking, if you stumble on a problem you cannot solve yourself.
Large frameworks like .Net or big Open Source projects usually have enough users and support groups and specialists that it’s likely any question you may have has already been answered somewhere or that you can pay someone to help you out when you need it most.
10- What do you know best?
Every framework is based around a particular data-management model. Every framework is built with a particular programming language in mind. Every framework demands that you learn something new.
How comfortable are you with the requirements? how long is it going to take you to start to get really productive?
Like their real-world counterpart, it can take very little time to learn a new language’s words and syntax but it takes years to become proficient in it. A framework adds another layer of abstraction that you will need to get experienced at.
If you need to both learn a new language and a new framework, chances are that you are at best months away from being able to churn code without having to look into the documentation every 5 minutes.
Learning new languages and concepts is necessary, but again, if you chose that route you must be sure that your project has that learning curve built-in, otherwise you’re going to move at the pace of a turtle when in fact you chose that particular framework because you though you would be more productive and faster than a sparrow.
If you chose a new framework, make sure that you already possess most of the knowledge it requires: in my particular instance, I chose .Net and C# because I have already worked in that framework and I know it can tackle the project without me having to waste too much time on learning the platform rather than implementing the project.
We all should seize any opportunity to learn something new. Learning is often more exciting than doing the same old thing over and over again and it’s a necessary part of staying in business. Curiosity is an excellent quality that must be nurtured and indulged.
The issue is when to do it.
Choosing a new development framework is not easy. The best way to tackle the problem is to pose it as a risk analysis study.
The framework you chose should simply be the one that poses the least risk to you succeeding your project.
October 1st, 2006
Next Posts
Previous Posts