Once upon a time there was an object.
He was very lonely, because noone used him.
His name was DB_DataObject.
He was a parent of DO_Client, and DO_Address.
His first adventure looked more or less like that:
Read the rest of this entry »
Archive for April, 2006
The secret of the leap from using objects to Object Oriented programming
Hallmarks of a prospective Good Developer ™
- "I can do better"- After finishing a task, no matter how hard it was, and no matter how brilliant was your solution - you keep thinking… "Wait a moment, but that could be optimised… And that might be improved…". This doesn't mean you aren't proud of this Brilliant Piece of Art you've just created – but you are aware of its potential shortcomings and are already thinking how to change it to improve some aspects of your work.
- "I know how to do this, but I've recently read about a cool technology/approach" - and you trigger your curiosity and try to learn something about the new approach/tool/idea/buzzword and are one of the first people to actually use it. How cool is that! I guess I'm not the only one who gets buzz from solving hard problems in tricky and original ways, instead of using "brute force methods" that worked a million times before. Usually – yes, they work, but they only solve the original problem, not the ones related to it, which you'll stumble upon just after you finish dealing with this problem. An example being – yes, you can DataBind some data from DataSet to your Controls in ASP.Net, but what happens if the data you want to display is not exactly in the format you expect? You can either place the "data formatting code" in your <asp:ItemTemplate> tags all over the place, or - substitute that DataSet for a IList of Objects which are smart enough to be able to present you their properties in the format you expect. Yes, this is more work, but it also complies with the DRY rule.
- Abstracting your coding from the interface - trust me, users don't care about the Databases, Entity relationships, PostBacks, Forms, any of this. They only want to see a screen/page which gives them the information they want, or an Easy way of achieving something.You have to simplify your Model interface to implement something like HumaneInterface to actually work on the Domain problems instead of Programming Problems.
My idea of a robust development infrastructure
Obviously every project, technology and company are different, but there are some common practices which, when properly implemented, may cause everyone in the team to be less stressed out by the whole concept of “collaboration”.
The basic idea is – don’t interfere with other’s work if you don’t intend to.
If you ever had experienced a hell of working on a shared network drive and overwriting other people’s changes, then I think you might appreciate this post.
What I usually do (or: try to to within available resources and within constraints) is:
- Each developer, and programmer – namely: everyone who modifies code or “required resources” (in Web development – CSS, images, etc) has his own development toy-server installed on their local computer.
- The database can be either installed aside the local server, but I advocate all developers to use a shared database installed in the local network. The drawback of this solution is obvious – anyone can modify the database and cause your version of the system to stop working. But the thing you gain is more important – you are sure that your changes are affected in others’ systems and that their code doesn’t cause any problems with the structure you’ve created. This can obviously cause some downtimes when the database schema changes radically, but these cases don’t change very often in real life, at least not in the later stages of most projects.
- Now comes the “internal server” used by developers to deploy the application for others’ usage. Typically this is the place where the “last good” version of the application is stored – and this place should be updated as frequently as possible (preferrably – by an automatic script triggered by any change in the code repository). The thing is – if you don’t have a way of automating the deployment of the code from the repository – this copy of the system becomes obsolete
- Internal Staging environment – place where all the “proper” testing takes place. This is suggested to be different from the “last good” version because testers may want to see if the bugs they submitted are resolved correctly in the “last good” version, but the “staging” might not be updated as frequently. The reason being – “last good” version can contain unfinished code which might cause the system to stop working, and the last thing you want is to have your “staging/testing” version down.
- Once per day/week/any other time (periodically) the “last good” version gets copied onto the Staging environment and gets sent to testing.
- When the staging version is good enough, which means – satisfactory in terms of bugs and functionality – we can consider copying it onto the Live system to upgrade it.
- I would advocate the “last good” and “staging” versions of the system to use a shared database, but you can run into all sorts of issues with that configuration, especially when changing the database structure. You just have to see what works for you and what doesn’t.
- As the Live system is the most crucial part of the infrastructure – I would advise the live database to be updated manually each time you do an update from the staging environment – to minimise the risk of data loss or corruption.
- Don’t forget to schedule backups of your live database from the stage when it contains important information!
This is all good and nice, but how to actually implement the process?
It obviously depends on your environment, as far as I’m concerned in the PHP environment it isn’t very hard.
What comes with help for you is:
- Both MySQL and PostgreSQL allow you to make a full database dump into an *.sql text file and import it into the target database – and this process can be automated (this is highly recommended).
- Subversion allows you to attach scripts to its events – the most frequently used handle is the .postcommit one, which executes every time a developer commits a part of the source code. This script should update the “last good” version by copying over the updated files from the repository into the “last good” environment.
- You can also create scripts on your internal testing server which will copy over the “last good” version to “staging” environment at wish, so you won’t waste time doing it manually – trust me, it isn’t a creative or rewarding task
As I say, this is just an infrastructure, now you need a good process in place for task management and responsibility management – but that’s a material for another post.
As for the project management – I’ve got one, in my opinion most important advice – dont’ use the paper. It becomes obsolete 10 seconds before you print it out.
Hello world!
Mhm Hello World indeed.
To kick off the blog I’d like to share a bit about my experiences with Microsoft SourceSafe 2005.
To make a long post short: Dont’.
While this is nice that SourceSafe finally enables users to do many new and cool things (like the automerge function, which allows multiple users to work on the same file at the time), the overall application interface really misses the point.
As a ToirtoiseSVN user what I really miss is the confidence I have in the engine. SourceSafe, especially when integrated with Visual Studio sometimes asks you a weird question, (e.g. “The file in the repository is newer than your local copy, do you want to update your copy?”) and gives a choice of either: Replace, Leave or Merge. Which would be fair enough, but you don’t have an idea what actually happened in the repository while you were working on the file, and there’s no way of previewing the result of your action – what you can do is to figure out the “safest” button and pray that SS won’t erase you or your coding partner’s work.
The biggest shame about SourceSafe is – it has the infrastructure in place, but the workflow is either inefficient (while locking files before other users) or unsafe – and the dialogboxes are misleading :-/
What is good about it – it now supports integration with external commands, e.g. running some scripts after each CheckIn.
The shame is noone seems to know how to use it or where to find these options, let alone, to be actually interested in how to use it to make work more efficient.
What I learned while developing PHP code on Open Source environment – that a full control of the process is King in software development. That’s why I’d like to see Microsoft’s Tools actually empowering users, not making some “magic in the background” for them.
Maybe you’ve noticed the word “users” highlighted in last paragraph – that’s how I feel while working in Visual Studio – not much of a Developer, just a “System User”, working in an environment, which knows better and helps me with almost everything so I won’t have to think too much.
While all these small aids and shortcuts are crucial when working with such a complex framework – some of them are actually leading to a poor code practices.
Consider the “drag and drop” of a table from Sql Server onto your Web Form.
What Visual Studio will create for you is a full stack of classes you need to access that particular database on that particular page – but it hardcodes the database connection string, and uses a non-optimised number of adapters, connections and supporting classes, and if you won’t refactor that “page” in the future your whole application will turn in a big ugly mess.
Sometimes I’m not sure if the direction of Visual Studio is actually the “proper one” in terms of developers’ coding practices – I’d like to know your views on that subject.
