It had to happen ... so it did. A bunch of Usability researchers have put together a simple little Firefox addon called Chickenfoot that helps you program your web browser to complete simple tasks. Just in case you are going whaaaa? Here is a small example of what you can do in Chickenfoot and you will get the idea.
-----
go("google.com")
enter("Rajesh Vasa")
click("google search")
----
They provide a few more functions to help perform common tasks, and the language they created is an extension of Javascript.
Opera has recently announced on their blog, that they too have started to add similar functionality and should seep slowly into their stable releases. Firefox will most likely not make this a core functionality, since this is not really something most end-users will care for.
Now why is this great? What is the pain point that they are attempting to address?
To start with, this is real cool -- but will developers bother learning it and using it beyond 15-20 min? One area that I think it can help a lot is in making a certain category of testing scripts -- and there is no reason why this cannot be used in a rudimentary way for Test driven development for web applications. The other area that it can be used is for developing Firefox extensions (it has a button in the Development interface to deploy the code as an extension). The language and interface are simple enough to be used as an educational language to teach someone getting into programming (or) is keen to learn a bit more about programming.
It is always good to see incremental developments that have a potential to have an impact.
Sunday, January 21, 2007
Wednesday, January 17, 2007
Problem Space Vs Solution Space
Software systems are generally built to satisfy a set of requirements. Unfortunately, typical requirement documentation states the intended solution rather than present the key problem. But, to build good software, the developers need access to the problem statement, ideally a set of pain points for each category of user. Why bother?? Because the developers are able to make better decisions.
A well stated pain point should be::
1. Specific (Clear, context sensitive and well scoped)
2. Measurable (ideally objectively, but appropriate subjective measures can work)
3. Current (as opposed to may happen in the future)
---
A simple example to illustrate my point::
Solution: "I want to take Road-43 and taken exit-10 to arrive at the airport"
Pain point: "I need to catch an international flight at 4:45pm from Airport-X, I am currently in Location-Y"
Software documentation is often provided as a set of solution statements.
This hides the context as well as the real issue making it harder (than it already is) for the developers (or problem solvers) to find the most effective solution.
Why does this matter? Because, software development is all about making a series of decisions. Decisions made with the context of the real problem are very different from those we make if the input is a partial solution. Good decisions more of then than not lead to good software.
------
Note: I am capturing these thoughts to be refined into a set of notes on how to go about building software systems. Feedback/comments are very much appreciated. I may edit old posts to clarify and better state my ideas as well.
A well stated pain point should be::
1. Specific (Clear, context sensitive and well scoped)
2. Measurable (ideally objectively, but appropriate subjective measures can work)
3. Current (as opposed to may happen in the future)
---
A simple example to illustrate my point::
Solution: "I want to take Road-43 and taken exit-10 to arrive at the airport"
Pain point: "I need to catch an international flight at 4:45pm from Airport-X, I am currently in Location-Y"
Software documentation is often provided as a set of solution statements.
This hides the context as well as the real issue making it harder (than it already is) for the developers (or problem solvers) to find the most effective solution.
Why does this matter? Because, software development is all about making a series of decisions. Decisions made with the context of the real problem are very different from those we make if the input is a partial solution. Good decisions more of then than not lead to good software.
------
Note: I am capturing these thoughts to be refined into a set of notes on how to go about building software systems. Feedback/comments are very much appreciated. I may edit old posts to clarify and better state my ideas as well.
Tuesday, January 16, 2007
On software developers...
In a recent interview, Bjarne Stroustrup (the man behind C+) said the following::
"I think [making computer languages easier for average people] would be misguided. The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and under-trained."
There are a few more gems like this in his interview, most certainly worth a read. Most experienced software developers would agree with much of the above statement. I however would add that computer languages should be designed to aid/improve productivity of a trained developer. This does not mean that they are easier.
One of the greatest improvements in productivity in a team development environment is the concept of a garbage collector. This is one aspect that C++ does not provide, and hence when using C++ for a solution it is best to have developers that are familiar with this limitation. Also, managers would need to understand that the benefits of C++ come with a very well known trade-off ... developers are just not as productive. When working in a team, it is important to know that the reference to an object/structure that you have been provided is safe as long as you use it -- developers being humans make mistakes and in a dead-line constrained environment you only need a few weak developers before it starts to get rather painful.
"I think [making computer languages easier for average people] would be misguided. The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and under-trained."
There are a few more gems like this in his interview, most certainly worth a read. Most experienced software developers would agree with much of the above statement. I however would add that computer languages should be designed to aid/improve productivity of a trained developer. This does not mean that they are easier.
One of the greatest improvements in productivity in a team development environment is the concept of a garbage collector. This is one aspect that C++ does not provide, and hence when using C++ for a solution it is best to have developers that are familiar with this limitation. Also, managers would need to understand that the benefits of C++ come with a very well known trade-off ... developers are just not as productive. When working in a team, it is important to know that the reference to an object/structure that you have been provided is safe as long as you use it -- developers being humans make mistakes and in a dead-line constrained environment you only need a few weak developers before it starts to get rather painful.
Wednesday, January 10, 2007
Apple iPhone & Apple TV - Initial thoughts...
I was very very curious like a lot of geeks about what the Phone would look like. So having seen the information presented from Apple, here are my initial thoughts...
- A touch-panel interface is quite risky, and will restrict the range of people that will buy this. The panel will get smudgy, I do not know how one can get around that. Until I use it, it will be hard to really understand or appreciate if it will actually work.
- It runs OSX .. an O/S designed to run a computer. I will have to assume that they will have re-worked quite a few bits to get it to fit into a phone. The real question is what they ended up sacrificing to get OSX to fit in a phone that small.
- 3 months after it is released, we will know if it will be a massive hit or not. But, I suspect that Apple will have to re-work and/or re-engineer many aspects of the phone over the next 6-12 months.
----
- Apple TV will be a hit (as predicted in my previous blog posting). The speed at which people will take it up may not be fast initially, but it will accelerate over time. The fact that you cannot record TV Shows on this device is a really interesting omission. I also think Apple will drop the price of this thing over time as they mass-produce.
Overall, very skeptical on the iPhone interface, I want to really use it before making a call on this one. Apple TV is very sleek and a lot of people will buy it.
- A touch-panel interface is quite risky, and will restrict the range of people that will buy this. The panel will get smudgy, I do not know how one can get around that. Until I use it, it will be hard to really understand or appreciate if it will actually work.
- It runs OSX .. an O/S designed to run a computer. I will have to assume that they will have re-worked quite a few bits to get it to fit into a phone. The real question is what they ended up sacrificing to get OSX to fit in a phone that small.
- 3 months after it is released, we will know if it will be a massive hit or not. But, I suspect that Apple will have to re-work and/or re-engineer many aspects of the phone over the next 6-12 months.
----
- Apple TV will be a hit (as predicted in my previous blog posting). The speed at which people will take it up may not be fast initially, but it will accelerate over time. The fact that you cannot record TV Shows on this device is a really interesting omission. I also think Apple will drop the price of this thing over time as they mass-produce.
Overall, very skeptical on the iPhone interface, I want to really use it before making a call on this one. Apple TV is very sleek and a lot of people will buy it.
Saturday, January 06, 2007
Predictions for 2007 (and beyond?)
Never done a prediction list before (officially), but I want to archive my predictions in order to review them at the end of the year and see how close I get.
-----
1. The earth will get warmer than before, yup - we are heating up. There will be even more evidence that humans play a big hand, and there will be many who will doubt/deny/question it. London will have another 40c day.
For some scientific and serious discussion - http://www.realclimate.org
2. The drought will finally break (Melbourne, Australia) between Feb - Jun'07.
3. Oil price will continue to climb. It will be > US$75 by Dec'07.
And now for some technology stuff::
4. Windows Vista will slowly start to seep into the developed world. Developers using the .NET framework will the first lot to move over, the rest will very slowly move over the next 3-5 years. Windows will continue to have security issues.
5. Linux will start to gain a lot more traction, with increased usage coming from South America and Asia. Device manufacturers will start to adopt it in greater numbers.
6. Apple will release a product line to start taking over the living rooms and are very likely to actually succeed. Most likely a Mac TV with the ability to save TV shows, go online and play simple games. It will be easy to use and very likely going to be a huge hit. They will grow their slice of the computer market.
7. The new Microsoft Office will most likely not gain much adoption this year (or the next for that matter).
8. 2007 will be the year that web applications extend their reach. Google will release a plug-in (or some technical module) that will allow GMail and their Word processing/Spreadsheet applications to work offline. This will start off a new revolution -- and a lot of clones will start off.
- Image processing applications will start to go web based (Maybe not to the quality and richness of photoshop, but they will hit the 80-20 rule without much effort this year).
- There will be attempts made at creating a completely online IDE. If you can have a word processor online, why not an IDE. This will be year the web application development will start to shift gears. Once the IDE shifts to a server, the whole deployment game will change as well. [The question is, will Google, Yahoo or Amazon release an IDE that will allow you to build applications to run in their infrastructure -- I hope so, it will be one of the biggest changes to the way we buil software in a long while]
- Assembling web applications using web-components will start to get a bit easier.
9. Offshoring and Outsourcing will turn around and the local development fad starts.
10. Custom software development starts to slow down for most business applications. It is now all about crafting a solution using existing technologies/components quickly. Integration, customization and selective enhancement will be the new buzz words.
** Personally, I hope #8 is spot-on and #3 is totally wrong.
-- Rajesh
-----
1. The earth will get warmer than before, yup - we are heating up. There will be even more evidence that humans play a big hand, and there will be many who will doubt/deny/question it. London will have another 40c day.
For some scientific and serious discussion - http://www.realclimate.org
2. The drought will finally break (Melbourne, Australia) between Feb - Jun'07.
3. Oil price will continue to climb. It will be > US$75 by Dec'07.
And now for some technology stuff::
4. Windows Vista will slowly start to seep into the developed world. Developers using the .NET framework will the first lot to move over, the rest will very slowly move over the next 3-5 years. Windows will continue to have security issues.
5. Linux will start to gain a lot more traction, with increased usage coming from South America and Asia. Device manufacturers will start to adopt it in greater numbers.
6. Apple will release a product line to start taking over the living rooms and are very likely to actually succeed. Most likely a Mac TV with the ability to save TV shows, go online and play simple games. It will be easy to use and very likely going to be a huge hit. They will grow their slice of the computer market.
7. The new Microsoft Office will most likely not gain much adoption this year (or the next for that matter).
8. 2007 will be the year that web applications extend their reach. Google will release a plug-in (or some technical module) that will allow GMail and their Word processing/Spreadsheet applications to work offline. This will start off a new revolution -- and a lot of clones will start off.
- Image processing applications will start to go web based (Maybe not to the quality and richness of photoshop, but they will hit the 80-20 rule without much effort this year).
- There will be attempts made at creating a completely online IDE. If you can have a word processor online, why not an IDE. This will be year the web application development will start to shift gears. Once the IDE shifts to a server, the whole deployment game will change as well. [The question is, will Google, Yahoo or Amazon release an IDE that will allow you to build applications to run in their infrastructure -- I hope so, it will be one of the biggest changes to the way we buil software in a long while]
- Assembling web applications using web-components will start to get a bit easier.
9. Offshoring and Outsourcing will turn around and the local development fad starts.
10. Custom software development starts to slow down for most business applications. It is now all about crafting a solution using existing technologies/components quickly. Integration, customization and selective enhancement will be the new buzz words.
** Personally, I hope #8 is spot-on and #3 is totally wrong.
-- Rajesh
Subscribe to:
Posts (Atom)