I was involved in the Beta testing of Daylite Touch for the iPad and was invited to write a case study describing how my business benefits from using Daylite and Daylite Touch for iPad. Here’s the published case study.
Archive for the ‘Business’ category
My Daylite Touch for iPad case study
December 16th, 2010Busy consultancy life, growing family, and blogging
October 28th, 2010Just posting because i haven’t posted in months. This is just a post about the interesting balance (or potential lack of it) when running an IT consultancy.
It’s an odd one – business is booming; clients are a-plenty; clients are happy and all extending our working contracts; all is smooth and rosy. But, in this focus on business growth and client satisfaction, there’s little time to give to feeding back into the community: I’m not attending many events; i’m not blogging much; i’m not tweeting many interesting finds. I’m just working hard, making clients happy and getting paid.
I do know others in the community who focus very much on their relationships within the community, and more on sharing and expressing than on earning. I know others who have a dedicated focus on creating products for the future.
So, i have to say that mine is a short-termist view: Generate the revenue and deliver. Of course, along with that comes the creation of some great business relationships (clients and partners), but it’s highly in the present and focused.
So, in fairness, with my family’s desire to move into a much bigger house, i have to say that the business focus isn’t planning to shift within the next 6 months. After that, we’ll see. I definitely want to create a saleable product. Of that, i’m very sure.
More meaningful posts later…
Important iPhone Push Notification consideration
April 16th, 2009A point worth noting by all iPhone developers considering the exciting opportunities of cloud-side iPhone app notifications – how much will it cost you to provide this service?
An important point to consider.
Now we’re rocking! DSL story driven development and testing in Java!
December 9th, 2008At TechnoPhobia, we have an interesting challenge to implement a technology agnostic requirements capture process that (in my mind) will enable us, with very minimal effort, to repurpose these documented requirements into fully automated browser tests. I’m thinking that the process could look something like this:
- The project and client team write end-user functional requirements as User Stories and Scenarios
- The stories are stored as plain text in SVN or GIT and made immediately available to the development and test teams
- The development and test teams create a few executable padder files, wrapped around these stories, turning them into fully automatable browser tests
- The executable files are run, they read the stories and interact with the browser to determine if the stories successfully pass
Pretty cool, huh! No more massive team specific documents, just good old plain textual stories that are shared by all on the project, including the client.
Making this happen across multiple technologies
- In Ruby, we’ve already used this parts of this approach on a live project using Cucumber (formally RSpec story runner). It worked pretty well.
- In Java, easyb seems to be the a good forward. Here’s a little more about using easyb
I am WAY TOO EXCITED to see an implementation in Java! This opens massive opportunity to progress with a technology agnostic approach. Now to find a suitable solution for .Net and perhaps PHP
Dave Thomas: Security as a measure of effectiveness
October 26th, 2008I really like this approach – Assess the state of security within a development team and project as an indication of how well a project is going and how effective processes are working out.
It’s another one of those many obvious tests that we all do, but at times i’ve certainly found myself accepting insecurity within a project team as one of those things because the team are new to the pressures or software projects are always uncertain and as such stressful. With a little consideration, it’s clearly more useful to use perceptions of insecurity as more direct indications that change is required.
What might we be looking for? A few possible ideas:
- How secure are the developers about the quality and stability of their code?
- How secure are the developers about rolling code to the various hosting platforms?
- How secure are team members about their relationship with others on the team?
- How secure is the project manager about hitting the deadline?
- How secure is the account manager about conversations with the client?
- How secure are senior management about project and team performance?
The overall intention of improving security is to make everyone feel relaxed. Software development is meant to be fun after all!
Source: Agile Toolkit Podcast ‘No fluff just stuff 2006 tour’
