Posted by David Glassborow
Thu, 12 Jul 2007 15:26:00 GMT
Like a number of people in the Delphi Community ( Steve Trefethen, Dan Miser ), and the development community as a whole, I now do all my development on a MacBook Pro. I changed to an Apple machine six months ago, for a number of reasons:
- I needed a new laptop, and the MacBook Pro hardware is so goddamn thin, light, and good looking.
- I am becoming increasingly disillusioned by Windows, especially the new DRM stuff.
- I fancied trying out OSX, a change is as good as a rest and all that.
- Bootcamp and virtualisation allow me to use Windows XP on an Apple laptop.
- The web is freeing us from being locked into particular Operating Systems.
As a professional developer, most of my clients run Windows, and most of my native development is done using Visual Studio 2005 or Delphi 2006, connecting to SQL Server or Oracle backends. I boot my laptop into Windows to do this work, or use Parallels to run it with Mac OSX (when I got my MacBook Pro I got it with 3G of RAM so Windows runs pretty fast inside OSX). Increasingly though I am doing web development, which means I can do much more work inside just OSX.
The more I have used OSX, the more I prefer it to Windows, so I have put together this list of tools and hints for doing professional development on OSX:
Using Bootcamp
- Steve has got an excellent list of the keyboard mapping for Windows
- Parallels allows runs Windows (from a bootcamp partition) in OSX
- As does VMWare
Using OSX
One of the things there first confused me using OSX is the link between a visual Window and a running program. Having used Windows for the best part of 15 years, I had the stong mental link between having a open window and having a program running. OSX is much more like the systray in a way. In most instances, a program carries on running even if all its windows are shut. At first this seems odd, but now I am actually used to Mail and iCal running in the background, collecting mail and showing me reminders, without having windows cluttering up the place or being minimised. Also the dock changes icons depending on status of the program, so I can see that new mail is waiting, without requiring an open window to tell me.
I guess it is the unix heritage, but OSX seems much happier having loads of programs running a the same time, than Windows would (or maybe this laptop has just got too much memory).
Another change from the Windows way of thinking is about installation of software. In OSX an application is a directory with a name of BlahBlah.app. It contains all that is necessary to run. So drag and drop to install software, move things around as desired, and delete it when no longer wanted. Only software that needs to make system changes needs to have install scripts.
You need to install Quicksilver for launches programs, and more advanced voodoo. Have a look at some of the screen casts at The Apply Blog, a good beginner one is here. You won’t believe for a powerful bit of software it is.
Another thing worth getting your head around is this idea of OSX services. These are simple ‘services’ that are provided to all programs running, accessible of the programs menu. While there are some useful ones built in, there really come into the own where you start changing them using Service Scrubber and This Service. See some examples from John Gruber about writing your own scripts and making them available to all apps (although I’d recommend using Ruby over Perl ;-).
Web Development
It goes without saying that you should be using Firefox with Firebug for web development. Day to day browsing I use Camino which is the firefox engine inside a more OSX integrated and looking program.
- Textmate is a great editor, as most people know, but if you are doing any JavaScript development make sure you get the JS Tools bundle. Having your script ‘lint’ed everything you save is a great productivity improver. Also get the GetBundle bundle to make it easy to manage extensions and find new ones. Blog writing is easy with the built in markdown support.
- Eclipse (especially with the new CodeGear betas running inside Eclipse ) has plugins to do pretty much everything (although I still use Textmate most of the time).
- Anybody know of a Fiddler equivalent for OSX ?
Subversion
Does anybody use anything else anymore ?
I use the tigris plugin scplugin to have subversion integration with the finder. It is not quite as good as tortoise. There is also Svnx which is ok, but I don’t find the UI all that intuitive.
Database Access
For connecting to Oracle, I use the free SQL Developer which has a native OSX version. Most of the open source databases have native clients (e.g. Postgres), but otherwise I use Aqua Studio v4.7 which is free. One of the nice things is most of the tools are Java based, so if you can find a JDBC package for your database, chuck it in /Library/Java/Extensions and then all the Java apps on your machine have connectivity to it (I have found ones for SQL Server, Oracle, MySql and Postgres).
Other Languages / Database Engines
- Anything available in the Open-source world, if not explicitly released for OSX, is normally available on DarwinPorts or Fink, projects to make linux/unix software compilable on OSX (which is a unix variant behind the scenes), and easily installable handling all the dependancies etc.
Are there any useful development tools or hints I have missed ? Let me know and I’ll try and keep a development bias list here or on this page.
And if your still using boring old Windows, come and join the revolution !
Posted in Web Development, OS X, Business, Delphi | 5 comments
Posted by David Glassborow
Thu, 12 Jul 2007 14:00:00 GMT
I am currently coming to the end of a large project for one of our clients, where I have been acting in the Business Analyst and Technical Lead roles. It has been a fun and successful project, and I wanted to pass along some of the lessons I’ve learnt (again) about how to make Technical Analysis (and the project as a whole) successful (and also make a checklist for next time around ;-).
It must be remembered that IT solutions (and really any business change) are all about two things: Incentives and Trade-offs.
Incentives
Incentives are important because ultimately people are lazy, and this is A Good Thing. We all have way too many things to do in our lives, both personal and professional, and therefore being lazy is a very successful evolutionary adaptation on the part of Homo Sapiens. The body only bothers to grow stronger muscles when we actually need them, rather than paying the cost of having them all the time. The same approach can be seen in our behaviour.
To make people want to use your new approach / program / business process, you need to make it worth their while. This seems obvious but I see it being forgotten time and again. Sometime the incentive is fear of being fired, but ideally you want to make your user’s lives easier and more efficient. If you can’t incentivise them to change their behaviour, they won’t.
Trade-offs
Any new system involves trade-offs. If it was a simple no brainer, it would have been done ages ago. Management often want better visibly of information (and normally control as well), but they need to be made to understand that this will have added costs, whether that is in increased paperwork, administration, or work enjoyment for the staff. Often people assume they get increased efficiencies (or whatever) for free, but there is always a downside. Not that that is a problem, but it needs to be understood and communicated (it goes into the areas of risk management). Communicating this as quickly as possibly, and ideally suggesting different cost/benefit scenarios, makes sponsors think more about why they are asking for things, and better controls their expectations.
From these two overriding principles, we then have a randomly ordered list of my current best practises.
Technical Analysis Best Practise
- Always sit with the users
- It’s all about incentive
- Mastery of language is important
- Its easier if you don’t care
- Avoid the middle men
- Flexibly and Power => Complex and slow
- Easy to think != Easy to do. Details matter
The above points in more detail:
1 - Always sit with the users
Sounds obvious, but on every project I see it being ignored. 30 minutes of sitting with the actual users you are providing a solution for, will give you better and more accurate understanding than talking to management or reading analysis documentation for days. Business processes change, often the experts on that process are out of touch with what is actually going on. As well as getting a good detailed understand of what they do, and what their problems are, another benefit of watching users is how often there are tiny little changes you can make (trivial software changes like adding a shortcut, or making some non-modal) that can save each user huge amounts of time and stress everyday !
If you haven’t sat and watched your users recently, you’re probably not building a system that solves their real problems !
2 - It’s all about incentive
A reiteration of the point about, but really a reminder to think of the incentives of each distinct groups of users. Management will have different incentives than the day to day users. It is worth thinking how to incentivise each different group to use the system in the way you want it used.
3 - Mastery of language is important
The language you use, both in your application, but especially when communicating ideas and progress to project sponsors, is incredibly important. Firstly words are very powerful in the human mind, they are the key way we link thoughts, feelings, expectations and fears together. The project I have been working on was half way through when I came on board, and because it was late and not delivering, had a number of perceptions, worries and expectations, all hanging off the ‘name’ of the project. One of the first things the team did was change the project name. This gave us a blank sheet to work with, meant that people’s previous perceptions were ‘invalidated’, giving us breathing room to solve the problems in a different way.
Secondly, unless you use terms like Risk and Trade-off, management and sponsors won’t consider these things. Just by using the words, you can make them better consider that they are asking for, and incentivise them to make better decisions (I am labouring the theme enough yet ? ;-)
4 - Its easier if you don’t care
I am an outside supplier, so it is much easier for me to tell people the situation as is, rather than having to worry too much about internal politics. You obviously don’t go out of your way to cause problems, and need be sensitive to the people from the business that you work with who don’t have the same freedoms as you, but being truthful about situations is very important to the overall success of a project. Having said that, obviously always keep copies of all emails, and confirm verbal conversations via email, so you always have an audit trail to support your decisions.
5 - Avoid the middle men
In any remotely large business there will tend to be lots of layers of management (unless you work somewhere very groovy like Google Inc). Each layer will have there own agendas, desires and aims, and will wish to communicate information in ways that either make them look good or at least reduce how bad they look. Whilst this is understandable, and just human nature, projects are much more successful if you can talk honestly to the ultimate users at one end of the spectrum, and the key sponsors / decision makers at the other end. The more layers in the way, the more the problems, drivers, issues, etc. get obscured and less clear. Politically this can be hard, and take time, but it is worth it in the end.
6 - Flexibly and Power => Complex and slow
This is really a more concrete example of the trade-off principle. Flexibility and powerful is what everybody wants their computer systems to be. However these two requirements ALWAYS imply complexity, and complexity implies complex (and potentially) slow running software. The art of being a good designer or architect is coming up with abstractions that are both powerful and a simple as possible, but always remember that powerful and flexibly implies clever decision making which implies complexity. Bacteria are very simple, but don’t do a huge amount but breed. Look at the complexity, both in body and mind, to get something as flexible and powerful as a human being. Fight to keep things simple, and your are much more likely to get a working solution ready in time.
A good example of this is the control issue. Management quite often want to stop people using systems in certain ‘incorrect’ ways (not entering data in certain ways, formats, sequences, whatever) . Often their approach is to wrap these systems in further layers that prevent the ‘incorrect’ use from occurring. Two problems with this though: 1. It’s loads of work and 2. There are often certain exceptional situations where it is necessary to put in data ‘incorrectly’. Often the simpler approach is just to provide an exception report. Management can use this to make sure systems are being used correctly, and if there is a valid reason using it wrongly, its not a problem. Making it a management rather than IT issue.
7 - Easy to think != Easy to do. Details matter
This is obvious to developers, but sometime can be hard to communicate to project sponsors. It is something I still have problems with conveying successfully. Steve Yegge discusses the same point. For the same ‘lazy’ reasons as discussed at the start, people don’t think through what they are asking for, and whilst this is annoying, your job as a technical analyst is to communicate the consequences of what people are asking for. In a similar vein, any technology you have been asked to use should be ‘proof of concept’ed as quickly as possible. Things often work in principle, but in practise are too buggy, slow or unreliable to actually use in production systems. Ultimately this is why I don’t trust analysts who can’t program, they never understand the need to capture the exact details of a project, because they don’t actually have to build working systems, they don’t really realise its importance.
Hope this list is useful for somebody. I’m off to work out what the trade-offs and incentives for writing blog articles are ;-)
Posted in Business | no comments
Posted by David Glassborow
Sun, 07 May 2006 14:58:00 GMT
Why Blog
Because:
- There are lots of technical details about delphi I’ve explored that may be useful to other developers.
I’ve learnt loads from the Delphi community and I’d like to return the favour
- There are lots of design ‘discussions’ (i.e. arguments) i’ve had with other developers,
especially my busness partner, and I’m interested in the opinions of other people on the issues
- To quote Paul Graham: “Expressing ideas helps to form them”
I’ve been meaning to write a blog, and host it, for a while, but haven’t got around to writing a web application to host it (although I’m still looking at doing it in RoR just to learn what all the fuss is about. So I’ve decided to host this on blogger for the moment, and maybe move it at some future point.
I’m going to write all the posts in markdown because thats the format we use
internally at work, and its very easy to work with. If anybody knows any groovy tools that can markup delphi code into a web blogger friendly format, I’d really appreciate it.
In development, my prefered tool is Delphi, for lots of reasons. The greatest thing about it for
me is that it comes with all the source code. My coding quality has improved more from reading the Delphi sources than anything
else.
I live in the south west of England, in the UK. I live here because of the quality of life, especially being close tp the coast. In my spare time I love surfing, running, travelling, and going on expeditions to far away place like Guyana and West Papua.
Concept First
I work as a technical consultant for a small software company I started with my business partner, Dan Jones, called
Concept First Ltd.
We are in our fifth year of trading, and do various types of work:
- Business Process mapping and development
- Web sites in ASP, Coldfusion, Websnap
- Application development in Delphi (by choice), VB6, VB.Net, C# (by request)
- Anything else that pays the bills !
A large number of our projects are integrating data in Enterprise environments (i.e. lots of random technologies chosen for reasons other than technical, fighting with vendors to get access to data, dispairing at money being wasted left right and centre …)
Technologies
At Concept First we like and use:
- Delphi
- DevExpress grids
- Apache 2
- Subversion
- SQL Server (especially MSDE/Express editions)
- Anything to do with geospatial data and mapping
- Mind mapping software for writing specs
- Bulleted lists ;-)
We dislike:
- Analyists who can’t develop
- Developers who can’t analyse
- The new hoops you have to jump through to be a Microsoft Certified Partner company
- Tying ourselves to Microsoft technologies
- How bad most enterprise software is
- How fickle the software industry is for the latest silver bullet
- Fixed width webpages and tables for layout
Articles
I’ve got various ideas I want to write up into posts, to be done when I get time/motiviation:
- Rich RTTI in delphi objects
- Delphi’s class helpers, good or bad OO design ?
- Websnap: good and bad points, how to extend it
- Websnap and FastCGI
- Null Object pattern in databases vs. explicit NULLs
- Case sensitive languages and why they must be destroyed
- Functionality vs Complexity - Time vs Money vs Quality
- Business Logic in databases
- REST vs SOAP
- Tips to prevent premature optimisation
I also need to convince my business partner, Dan, to sort out a blog, coz I’m bored of him preaching to the converted.
Expect some rantings on ‘semanctic markup in html’ asap :-)
Posted in Business | no comments | no trackbacks
