7 Life Lessons From A Self-Taught Programmer

I always had a thing with languages. For some reason, I always found it easy to learn them, and had a great time using them. Surprisingly enough, I followed a tech high-school, majoring with a diploma as a programmer in… FORTRAN. After that, I went to the University of Letters in Bucharest, where I studied Romanian and French literature. And in the last 10 years I had my own online publishing company, where I wrote more than 70% of the source code for the underlying software platform.

Why I’m telling you all this? Not to show you that my career life was a roller-coaster, if you read my blog for some time you already know that. But because there’s a link between spoken languages and programming languages. At a certain level, they’re both a vocabulary over a grammar. A programming language can be learned and applied just like learning French or Japanese.

Reality Is Created With Words

If you ever learned a foreign language you remember that special feeling of expansion, both inward and outward. It’s like space is growing around you. And that’s because every time you learn to describe the world in a new language, you actually redefine it, you reinvent it and enjoy it as a completely new reality. L’amour en Francais it’s a completely different thing from love in English, or from dragoste in Romanian. They’re actually new realities. Learning a new language is a beautiful travel.

Now, a programming language is almost the same. It enlarges your mind and gives you access to areas in your life that you didn’t even know they exist. It puts you in uncomfortable situations and forces you to solve complicated problems. Every new app that you start coding is like a trip to Thailand with only a pocket Thai dictionary. When you start the app, you barely know how to say sawasdee, but at the end of it, not only you know how to have a conversation with the locals, but nobody will be able to tell that you have an accent.

7 Life Lessons From A Self-Taught Programmer

I recently finished a very dear project to me, an iPhone / iPad app based on my own life management framework, Assess – Decide – Do. The app is available on the App Store, by the way, and it’s only 3.99. It took me 30 days to put together the first version, but around 90 days in total to have a solid, mature and feature packed app. During this trip, I had an incredible time, learned tremendously and thoroughly enjoyed every breakthrough. What follows is a collection of life lessons learned as a self-taught programmers, mainly while I was coding iAdd.

1. Bugs Are On You

Always. Don’t blame the compiler, the lack of documentation, or the horoscope. You made a mistake somewhere. At some point, something happened in one of your Assess – Decide – Do cycles (yes, you have those cycles even if you’re not aware of them) and you screwed something. I spent countless hours trying to find a flaw in some class or API, basically banging my head against the wall by not accepting that I was the source of that mistake. A typo, a bad copy/paste, or whatever: every bug was in fact my own responsibility.

It’s the same thing in life. If there’s something wrong, check your own history. Don’t blame somebody else. It’s not the universal compiler’s fault (if there would be such a thing like a Universal Compiler, anyway). There’s no glitch in the Matrix. There’s no failure in the Universe. It’s in you. Look in the mirror and try to find out what you did wrong. And then solve it.

2. You Have To Face The Problem, Detours Are Not An Option

Even if you don’t like it, in programming you have to take the most “difficult” path simply because there are no other options. Workarounds are fragile. They may solve the problem for the time being but their fragility will show up the moment you’d want to expand your app. Do it the right way, fix the problem for good. Or, if you settle for workarounds, expect things to blow in your face the moment you’re expecting this the least.

It’s like in life: you can’t live in a continuous status-quo. You gotta take responsibility for your choices, climb the mountain you have to climb, because the solution is always on top of that mountain. You can’t take a detour. Or if you choose a detour instead of facing the problem upfront, you may overcome some temporary difficulties, but you won’t find the real answer. The real answer is always on top of the mountain.

3. Today’s Problem Is Tomorrow’s Laughter

If you learn constantly, what seems difficult now, tomorrow will seem like a joke. Not only once I hit “impossible” situations in my coding, but staying with them long enough made them fade away. I remember the feeling of frustration and powerlessness every time I had to learn something new. Every time some new class showed up, some new algorithms appeared and I felt like I will never finish. But I did. And I laughed at my own frustration afterwards.

If you really take the time to look back at your life, you’d be amazed how far you’ve already gone. Just try to remember how was your life 5 years ago. How much was changed in your financial life? In your personal life? In your career? If you did your homework well, as in the number two above, the answer will amaze you. But if your answer will fill you up with sadness and frustration, go back to number two above and climb your mountain.

4. Good Focus Builds Good Things

The temptation of having something running out as fast you can, publishing it on the AppStore and waiting for the cash to pour in is big. Tens of thousands of programmers are hitting this road just like the gold rush in Wild Wild West. But if you look at the top 10 apps they’re all solid, verified, tested and really polished apps. Hurrying up is not a good solution. Especially in a highly competitive ecosystem like the App Store.

They say “all good things come to those who wait” for a reason, you know? You can’t expect to go on with quick fixes for ever. And yet, the perspective of waiting will frighten you up. So bad, that you’ll just run with something that works for the moment and lose sight of the big picture. Doing things incessantly, just for the sake of coping with your day to day challenges won’t take you far. Take some time to think things over.

5. If You Feel It, Do It

Many times you won’t have the tools to query your user base about the features they’d want in your app. You’re either an indie developer (like me), or the company doesn’t have a budget for creating focus groups or there’s nobody watching the forums, etc. Fact is you’ll have to rely most of the time on your own intuition when it comes to adding or eliminating features from your app. So, if you feel like something new will fit in, just go for it.

Of course, there will be times when you’ll be hit by the “feature diarrhea” but that’s a risk you’ll have to take. In time, you’ll develop a fine sense of what’s appropriate and what’s not. And you’ll grow that sense by practice, by direct interaction, by doing stuff.

That’s exactly with life decisions. When you feel it, go for it. Don’t delay, don’t ask for permission. You know better.

6. Be Neat

If you ever wrote a project with more than 5 source code files, you know that managing those source code files can be a nightmare. At this point, iAdd has almost 200 source code files. It would have been impossible to manage them without being organized and neat. By the way, iAdd was developed from the idea stage to the final implementation stage using Assess – Decide – Do, my life management framework. Without a formalized methodology in place, the project simply wouldn’t have been finished. Never.

If you have unfinished things, unspoken sentences or forgotten promises, uncover, speak out or fulfill. Don’t leave things floating around, hoping that someone else will come over and take care of them for you. Nobody will. It’s only you and your life. Keep it in order. Even if you did a mistake, a neat mistake is far easier to be repaired than a complicated one.

7. There’s More Than One Way To Skin A Cat

And perhaps more than 10 ways to implement an algorithm. In my early days as a programmer, I always was afraid there isn’t any way to do it. Now I’m afraid that I won’t choose the right way to do it. You always have more choices than you think you have. The same algorithm can be implemented in dozens of ways and a problem can be solved in thousands of ways.

That’s the same in life. If in the beginning you’ll be afraid that you won’t reach your goal, as you advance and learn, you’ll be afraid that you didn’t chose the most simple and effective way to do it. The subtle lesson here is that there are always solutions. Abundant, flowing and ready to be used. Embracing risks and daring to be different will teach you that nothing is impossible.

Nothing.

Managing Online Projects in 5 Easy Steps

You have clients, deadlines and tons of work to do. You have to deliver results and stay on top of your lists. You have to be productive. Otherwise you’re out of the game. And being out of the game is not fun.

I had an online business for more than 10 years and I pretty much know all the thrills of it. It’s engaging, passionate and filled with action. You don’t have time to get bored. Unless you step out of the game. Which, as I already said, it’s not fun.

Over the years, I created, implemented and launched more than 25 online projects. Each with its own budget, promotion, human resources and logistic. Some of them had 2-3 years projections and even more. Some of them become market leaders, some of them dropped dead after a few months. And despite their success or failure I enjoyed doing them all.

In today’s post I’ll share the process I used to make all those projects alive. It got refined over the years, adding something here, cutting something from there. It aims to be simple enough to be applied to a niche blog, but sustainable enough for the next huge social network hit. Which is exactly what you’re working on right now, of course.

Online Projects In 5 Easy Steps

Every online project would answer to only 5 questions, and those are:

1. what is it?
2. who’s going to use it?
3. how does it look?
4. what does it do?
5. how can I do it?

Each question has its own role and specific implementation techniques. I told you, it’s not complicated. Let’s take them one at a time:

1. What Is It?

This is the cornerstone of your project. It has to be contained within only one sentence. For instance: google is a search engine. DMOZ is a link directory. Mashable is a social media blog.  You got the idea. Keeping it in only one sentence prevents you from starting mutant projects, with overlapping or even opposite functionalities. Usually, the first answer that pops into your head is the correct one, although you can get some improvements if you brainstorm it a little.

From my experience, if the root of your project is not clearly defined, you will have serious troubles later on. Too many times, on a technological, geeky rush, we tend to skip this step and go straight into implementation details. As fun as it may be for some of us, the development part is only the 5th part of this set of questions. Skipping the first 4 points will be like dining out naked: you can be sure you’ll make a huge impression, but you cannot be sure it will be the desired one.

2. Who’s Going To Use It?

The second question is about the beneficiary: who’s going to actually use your product? This is what I call “role playing project management”. Oh, this is the most entertaining question of all, that I can tell you. Impersonating other people is always fun. Trying to actually picture the portrait of a standard user for your project is enlightening. In a mirroring way, finding the fundamental traits of an ideal customer will reveal parts of your project you didn’t even know you had.

Another interesting segment of this step is to identify at least 3 consumer characteristics of your ideal user, regardless of your project. It’s a very fun exercise. For instance, how often does he goes to the movies? Or what kind of car does he drive? What tooth paste does he use? Does he use toothpaste at all? You may think right now: what’s the link between the toothpaste of an imaginary character and my online project? Well, if you can’t imagine the user of your project, chances are he doesn’t really exist.

3. How Does It Look?

This deals with the actual support of your project. An online project is not only a web site. It can spread unto other protocols, like email, or mobile. Most of the time, your online project will have at least web and email as its basic information support, but with the latest deployment in the mobile industry, including iPhone, you will have to include mobile as standard pretty soon.

Also at this level, you start to identify the type of messages you are going to use. It could be text, images, animations, video or audio. This step is mandatory and it will have an important impact in the final step. Many project managers call this “provisioning”, I used to call it “how does it look”. This stage will also be responsible with the logical structure of your project: home page, content pages and the relationship between them. You’re wireframing. And while you’re wireframing, it’s pretty smart to start designing your own SEO strategy before adding content to your product. Identify target keywords and hot content areas.

4. What Does It Do?

Slowly, we’re getting there.The 4th question deals with the flesh of your project. If wireframing means constructing bones, now you’re adding some flesh and blood. In this stage you’re defining your features list. Starting from the simple ones, like “I want a link bar at the top, containing these links” up to something like “this workflow will enhance user experience and make him stick with our product”. Or something in between.

I often found that in this stage of a project you can create some very basic unit tests. Don’t freak out, it’s nothing complicated, just a list of desired actions and expected results. If you create an ecommerce site, one of your desired activities in your estore could be “putting products in the shopping basket’‘. And the expected result would look like ”updating database with new values and showing this on to the user“. It can get complicated, of course, but this approach it’s a gold mine especially if you switch teams a lot.

5. How Can I Do It?

And it’s only in the final stage that we’re actually doing it. And we don’t even start with doing it, we start with planning it. Yeap, so far we didn’t have any plan at all. It’s time to create milestones, chose our technologies, start coding and get on with the launch. This is by far the most exciting stage of an online project and many entrepreneurs are starting directly here. Now you understand why we had to chose around question no 3 the types of messages we will use. Because based on those choices we are choosing technologies right now.

From this stage ahead, you can leverage everything you learned about planing, coding and launching. This is pretty much what you do every day, only you can do it now without constantly asking if you’re doing the right thing. You already decided this. You already answered every question which could potentially become a leak in your planing. And that’s refreshing.

One more thing: after you finally launch the project, getting back to the question number 1 ”What is it?“ would be really interesting. You may have some surprises

***

This project management flow was part of a presentation I did a while ago at a local tech event. If you’re interested, you can download the mind map used for the presentation (a screenshot of it is just below this paragraph) Managing online projects in 5 easy steps (1602) - 146.54 KB. Also, feel free to ask any questions about this strategy in comments.

Assess – Decide – Do for Programming

Assess – Decide – Do is a simple life management framework. Despite its somehow pompous acronym, ADD is overwhelmingly simple, so simple that you may even overlook it. Every ADD cycle is based only on 3 fundamental activities: assess, decide and do. And since we’re going to talk about ADD and programming, we can borrow a little bit the object oriented paradigm: ADD is an abstract class, and every implementation you instantiate will be a subclass of it. It’s entirely up to you to create your very own ADD implementation in whatever area you want to improve. For instance, I already wrote about ADD for relationships, and will write about several more topics soon.

In today’s post I’ll sketch some outlines on how ADD can be used for software development. I do not claim to give you something complete, nor even formalized, but I’ll do my best to give you something you can use in your day to day coding activities. Being so simple, ADD gives you a lot of room on how to implement it for a specific area, as long as you respect 2 simple rules:

- at any time you can be only in one realm, being it Assess, Decide or Do
- the quality of the implementation is given by the Flow, or by the smoothness you achieve in traveling from one realm to another.

If you’re new to my blog, or never heard about ADD like this before, feel free to read the introductory series.

Assess For Programming

The assess realm is where you find out how your product / service will fit in the real world. Most of the time you already know that, because the client gave you some specs. In that case you can safely switch to the Do realm, and start coding. But there are situations in which you have to write something from scratch, to implement a new idea, to create a completely new service. Assessing comes especially handy in those cases.

In my experience I found at least 2 ways to speed up the assessment process: one is mind mapping, the other is role playing. At some levels those two can overlap.

Mind Mapping

One of the big advantages of mind mapping is its multi level structure. You can create a document with multiple levels, all accessible from the same point of view. This is especially useful in programming, since the initial phase of every new software project involves a lot of levels, from prototyping, functionalities, user interfaces, architecture and so on.

I find mind mapping to be especially useful for capturing new projects ideas. New ideas have this tendency to pop up in the most unexpected places and at the most unusual times. So, I keep my mobile device, which happens to be an iPhone, packed with a mind mapping application, which happens to be iBlueSky just in case. I think that 75% of my new ideas come from mind mapping them first in my iPhone.

Role Playing

Most of the time you write code for somebody else. The man who pays the bill is usually the client, but the real user of the app will not be the client. The real user will be the one who uses the app. One of the most interesting ways in assessing your programming is to do some role playing. Impersonate the user. Try to act and do as he will act and do. In the initial phases of a project, role playing is fundamental as it will reveal many of the functionality you didn’t even think at.

Of course, not all the time you’ll succeed, this is why outside focus groups are usually the next best thing. Unfortunately, focus groups are pretty expensive. One cheaper alternative would be to use a community of beta testers, usually created in some social networking sites like twitter or facebook. It’s a little bit unusual to use beta testers for prototyping, their role comes a little bit later, but if you can get together a team of fans or close friends to help you with this role playing game, that would turn out to be a very good asset.

At some point, role playing and mind mapping will overlap. You can start with a mind map about the interface and create several branches for each type of user you can imagine. You can role play with a mind map too.

***

Now, we talked about how you can assess, but nothing about what you can assess. One of the reasons for being a little bit cautious is the fantastic diversity of this topic. You can’t really create a cheat sheet of what to assess on such a divers field like software development. You can’t create a “one size fits all” approach here. But even if the software development area is so huge, I think we can find some common ground. Take what follow merely as an orientation map, rather than a cheat sheet.

Goal

• what is going to do the app? (usually in one phrase: Office is making text processing, Photoshop is making image editing)
• what is the problem that the app is going to solve? (some software creates more problems that are solving)
• how long the app is going to “live”?
• where is going to live? (operating system, device, programming language)

Features

• are the features atomic? (you can do the same thing from two insertion points?)
• are the features congruent with the goal of the app? (over packing with features)

Architecture

• if there is an OOP approach, class definitions, if there is a procedural language, function definitions
• modules / screens / menus
• semantic grouping of features (same like modules above but in a more abstract way)

Interface

• functionality wiring
• windows / buttons / links placement
• insertions points

Post launch behavior

• there will be some support?
• there will be updates? how often?
• there will be a constraint for some operating systems / devices?

Unless you already have in place a more formalized process for assessing a software project, that should give you a start. It’s important to mention that some of these sections will be re-assessed after a decision.

The “Decide” Realm – Backfiring

One of the most important characteristics of this realm (from an ADD point of view) is that in the software development, any decision will most likely backfire you at some point. Unless your assessment has been perfect, you will be facing some serious issues with your decisions and will talk about the reasons for that in a moment.

But first of all, what you decide in software development? Well, everything you assessed in the previous realm. In a perfect world you should have  a list of features, hundred of prototyping wireframes and a ton of crystal clear specs, and then only chose from them. In practice is not that simple. Not always the user interface will agree with some functionality and not always the architecture will be totally compliant with the operating system or programming language.

Decision in the software development process should be more close to compromise than in any other process. If you look for black and white decisions you will shoot yourself in the foot, sooner or later. And the main reason for that is the speed of technology. If you chose something now, you can bet it will be obsolete in 6 months. Your decision will be outdated. So, instead of looking for the perfect decision, you should look for the best decision in the moment.

There is no other field in which change is so present as in software development. Every 6 months a new technology appears and the change is fantastic. The users are changing behavior every 2-3 years. 5 years ago link directories were huge. 3 years ago hi5 was riding the wave. Now it’s Twitter and nobody really knows what it be tomorrow. The decision of staying with a specific platform will always be questionable.

That being said, let’s see how you can implement a consistent decision strategy.

1. Think in milestones – In software development, milestones are called versions. Limit your decisions to the next available version. Don’t plan too far, don’t plan to loose. Limiting the decision to the next available version means promoting the features and interface changes for a limited timeframe. Only until the next version.
2. Never change a decision until you implemented it – That comes from personal experience. I developed a web platform with hundreds of thousands of users and millions of visitors. At some point we decided it’s time to upgrade. But after a while we decided to stop. That was a mess. We should have follow the initial decision and after implementing it assess our success or failure.
3. Make the decision transparent – if you work with a team, communicate the decisions often. if you’re an independent developer keep a journal of your decisions. You already may have a tool for project management, but it’s especially useful to note not only the overall progress but your decisions.

The “Do” Realm – Writing Code

The “Do” realm in software development consists in writing code. Yes, that’s everything you should do. You know the features, the interface, you decided what you should do until the next version, so everything you have to do is to write code. But every guy who wanted to write a “Hello World” program knows that things are way more difficult than that.

Usually, the “Do” realm is very close to the “Assess” realm in software development. Every time you finish some code, you go testing and see if everything is ok. And you do that constantly, until you reach a certain milestone.

The main advantage of using this ADD framework is that you presumably have everything ironed in the first two realms, Assess and Decide, and all you do now is writing code. But you will go back to the Assess and Decide realm pretty often, until you reach a certain level of functionality.

***

Do you have other experiences with software development? Do you find value in this post? Do you have something to add? I’d love to hear about that in the comments.

Thesis Hooks for Twitter, StumbleUpon, Digg and Reddit

I love my wordpress theme, I really do. In case you haven’t noticed so far, this is thesis, one of the best commercial themes for wordpress. I don’t like it only for the crisp appearance and nice layout, you can get that nowadays from any decent free wordpress theme. What I like it for is the unparalleled flexibility of the backend. Not only it has 2 different admin pages full of options but it comes with one of the best features in the PHP frameworks: hooks.

Now it’s time to take a break and announce to our precious reader that this post will be a moderately technical one (yes, I know PHP pretty well, among other different skills ) and it will involve some coding. Now, let’s explain what this is all about.

Take Care Of Your Users

I use several social networking sites these days: StumbleUpon, Digg, Reddit and of course, Twitter. During the last few months I managed to attract a fairly amount of traffic from those services. To be honest, this traffic exceeds by far anything I get from search engines. And what I really appreciate at this type of traffic is its “human” touch. I might get some huge impact from a lot of bots that are searching for “iPhone 3g applications” (btw: I rank pretty well for that) but in the end what counts are the real persons who are seeing my posts promoted on the social networking services.

So, I thought it would be courteous for me to let those people know that I know from where they are coming and to start a little bit of interaction with them. I decided to have this interaction on two very hot spots in the wordpress territory: just before the post and just after the post. Sidebars, header and footer are not so hot when it comes to user action, the content rules. So, I wanted to have a simple line that would say hi to the visitor and tell him I’m on that specific social network too and a little reminder to help him promote the post, and another simple line in the end, letting him know how he can befriend me on those networks.

Pretty simple, of course. I know you can get tons of social networking features packed in a number of very specialized plugins but I didn’t wanted to use another plugin for that. I wanted to keep it extremely simple and easy to control. So, here’s how I did it (don’t worry now for the technical part, all the source code is packed and ready to download at the end of the post). (more…)

Taxonomic Twitter

In another post about Twitter I wrote extensively about the implications of this service from a behavioral perspective. It seems that I’m quite in a “twitter mood” lately since I’m writing another post so close to the first one and I’m planning another one for the upcoming days. Right now I would like to share something more technical about this.

It’s about an attempt to make Twitter even sharper and thinner, by using some sort of taxonomy, or in plain english, a method of grouping together posts by putting “labels” on them. Twitter already has a max limit of 140 characters for each post, and chances for this to grow up are likely to be zero. At least for now. So, in order to increase the readability of the tweets, all work must be done “inside” this 140 characters limit. And the way they’re trying to this is by using some extremely scaled down mark-up language.

They’re called hashtags and they are a way of identifying zones of related content. For instance, if you’re going to tweet a lot about raw food, you can insert somewhere into the tweet something like this “#rawfood”. The “#” sign will have the role to identify the string after it as a marker. Everything with a “#” in front will actually become a label. So every time you will be tweeting about raw food, you will group your tweets into a larger category of possibly related tweets. If somebody else will tweet about the same things and they’ll use the same marker, your tweets will be grouped together.

Using Hashtags Implications

First of all, there will be less room for the actual information. Every hashtag will eat some space out of the 140 characters, leaving less space for the original content. Chances are that your content could be grouped in more than one category, or marker and you’ll be inclined to use more than one hashtag in your tweet. If a consistent API would be provided for working with those hashtags – and chances are that there will be some hooks sooner than we think – then a lot of applications would be using that. Turning Twitter into a searchable catalog is just around the corner. There is a great potential for advertisers and even for people who are trying to promote their blogs or products. It would be the easiest way to direct your tweet to the intended category of readers. (more…)

Minimalistic GTD workflow: Getting Things Done with Do It!

Although a little too simple for my taste, Do It (formerly known as “To Do”) is one of the “oldies but goldies” around the Mac software community. Yes, I know, I am being mean, after all, “Do It” is only one or two years old – the author blog haven’t been updated since last year, but hey, we know how this works pretty well – but in today’s rapid moving world, two years may seem like a lot.

Do It is one of the “missed things from the operating system” that somebody thought to write, launch and maintain, filling a gap in the list of necessary applications. Looking at its structure, “Do It” only have categories and tasks (with priorities, deadlines, and linked files or URL’s). Simple enough for the less-than-average user, but flexible enough for an experienced GTD-er.

How can you use this tiny little Mac app in order to implement a slim GTD workflow? Easy, just name your categories like contexts (after you have correctly identified your contexts, of course). So, instead of thinking at your categories as projects containing tasks, think at them as contexts in which you are acting. Here’s the “Office” context, for instance, with only one task in it:

Adding a task is a question of hitting “option + N”, pretty much standard. The task details will be shown in a semi-transparent floating window:

One thing to note is that the task adding / editing window will resize itself, if there are other details to be shown for a specific task information. For instance, here we are editing the task’s deadline, and integration with iCal:

Did I mentioned integration with iCal? I guess not, but this is also one of the strong points of “Do It”. Another one will be the ability to export your tasks into an iCal-readable format (.ics) which you can later import into iCal.

Each task you add can have up to 3 priorities (colored red, orange, or green) and an external object linked to it, being it a file or a web URL.

Keep in mind that you won’t have real projects with this workflow, and you’ll have to correctly split your current projects into multiple actions, and set up your next actions, before adding it to “Do It”. You don’t have any filtering options, so you’d better chose the red color for your next actions, as the default ordering is priority-based, and like this you’ll have your next actions always in front of you.

“Do It” is ‘donation-ware’ so if you feel you want to reward the author, I strongly encourage you to leave a donation for him.

A very minimalistic GTD workflow can be implemented with the tiniest application in the world, if you really want. Which reminds me the fact that GTD is not a software you buy, but a process you implement and follow.

[tags]gtd, do it, minimalistic, software review, productivity, mac os[/tags]

How To Make A Google Toolbar Button For Your Blog

Google Toolbar is a great browsing extension. I use it since its only benefit was to show you the page rank of the page you visited. And it was a great tool. But things have changed and now Google Toolbar is making important steps toward a more socialized approach of the new web.

One of these new approaches is about the Google Toolbar buttons. The latest toolbar version, with the major number 3, which you can download here, has a very nifty feature that lets you add buttons on the toolbar as you see fit. Meaning you have unlimited choices and liberty to make anything you want out of the toolbar: adding buttons for your preferred recipe website, for your sport scores, or for the most interesting bloggers you know.

Google also put together a space where you can see buttons created by other people. Wow, wait a minute? Google just let me to publish my own button? Well, uhhmm, yes, the answer is yes!

Thats’ really awesome! That is a very interesting opportunity for you to promote your service, being a blog, or a corporate network.

In the next 2 minutes I’ll show you a very short description of how you can make a button for your blog. After making the button, and testing it, you can use this simple form at google buttons gallery to add your creation.

First thing first, let’s start with a simple template:

<custombuttons xmlns=”http://toolbar.google.com/custombuttons/”>
<button>
<title>eDragonu – personal development</title>
<description>A Romanian entrepreneur blog about personal development and getting things done</description>

<site>http://www.dragosroua.com/</site>
</button>
</custombuttons>

If you save this code above on a file ending with .xml you’ll have a pretty much functional Google button. You can also try to copy and paste the code above in the Google Toolbar advanced button editor. Of course, you need to replace the info between the title, description and site tags with your own information. But I don’t recommend it, doing it blindly will not give you much benefit in the long run. Let’s explain a bit:

1. <custombuttons> means the file will be interpreted as a custom button xml file, using a namespace defined at http://toolbar.google.com/custombuttons/.
2. <button> starts the actual button definition, here you will have all the info related to your button, like title, description and site.
3. <title> this is the title of your button, from my experience is better to keep it as short as you can.
4. <description> here’s you will usually put a sentence as clear as you can about what the button will actually do, or what your blog contains.
5. <site> the most important, your website address, that’s the place where you will direct users once they clicked your button.

And that’s that! Now that you know the meaning of each tag everything seems more clear. You now have a functional Google Toolbar button. But wait, there’s more! Is there any chance that I could add to this button something like a feed drop-down menu? And when you click the button you can actually see al the new posts without visiting the page? Of course you can! And it’s pretty simple too, just add a line like the one below just before the </button> tag:

<feed refresh-interval=”1800″>http://feeds.feedburner.com/Edragonu-TheChoiceOfAPersonalPath</feed>

Of course, replace the feed address with your actual feed address. Keep in mind that you will experience a pretty high load if a lot of people are starting to use your feed-enhanced button, so maybe you will want to tweak a little the “refresh-interval” option.

The new code for the button will look like this:

<custombuttons xmlns=”http://toolbar.google.com/custombuttons/”>
<button>
<title>eDragonu – personal development</title>
<description>A Romanian entrepreneur blog about personal development and getting things done</description>

<site>http://www.dragosroua.com/</site>
<feed refresh-interval=”1800″>http://feeds.feedburner.com/Edragonu-TheChoiceOfAPersonalPath</feed>
</button>
</custombuttons>

Pretty simple, right? If you want to really complicate things a little, you can also try to insert an icon, integrate a search query within, or even try to automatically adjust the icon based on your mood. All of these are possible, but you need to further read the documentation at Google Toolbar API’s page.

We’re now trying to finish the little tutorial with some simple instructions for hosting, testing and submitting your button to Google Button Gallery.

Once you’ve made your code, save it to a folder on your blog server. I highly recommend to save it on your root domain, so the button address will be something like:

http://www.dragosroua.com/edragonu_button.xml

This is important because this will be the actual address of the button, Google will not host your button for you, so if you change the address the button will be impossible to be found.

Once the button is in place, try to test it. I use this piece of code, saved on my wordpress template sidebar:

<a href=http://toolbar.google.com/buttons/add?url=http://www.dragosroua.com/edragonu_button.xml>add</a> to Google Toolbar!

It will give you something like this: add to Google Toolbar!.

Click on the link and see if the Google Toolbar is actually adding your button. If not, try to restart the button creation process, there must be a bug somewhere. But if everything went well, just go ahead and submit your button using this very simple form at google buttons gallery.

And don’t forget to load this button in your own Google Toolbar .

GTD feeds – my first pipe on Yahoo Pipes

I guess we all know the buzz on Yahoo Pipes. It’s a brand new service from Yahoo that basically offers you a visual interface for fetching, combining, programming and publishing various pieces of the Internet, most of all based on remote services, like RSS or SOAP.

What you can actually do with it? Well, you can fetch somebody’s photo stream from Flickr and then combine it with some news feeds, and voila, you have a pipe. There are some basic operators that you can apply on the content you fetch, and there are also some user inputs that you can assing and act on the result specifically. I haven’t tested the user inputs yet, but what I’ve done, it was to create a pipe-feed (sorry, the name sounds strange…) and try to see what I can do with it.

I took the feeds of some of the GTD bloggers I appreciate the most, combined them, and published under this link. For the lazy that doesn’t want to click away here’s a little screenshot of what it looks like, from a “visual” standpoint.

I must say that the visual development pattern of Yahoo Pipes is pretty powerful and reminds me a lot of Automator. But, as with Automator too, it needs some programming skills to actually produce something, as the list of published pipes on Yahoo already shows. There are a lot of “tests” and “copy of…” pipes on the stock there.

What you can do with this pipe? Well, you can subscribe to it, get results by email or phone, or get sent to you as JSON (Java Simple Object Notation). That will allow to our AJAX developers fellow out there to program the nuts out of it, by hyper-extending it, to, you know… space, the final frontier… (One note from the programmer-side of me: around a year ago I saw an AJAX tutorial written by Rasmus Lerdorf – the creator of the PHP language, among other things, and the wonder-boy at Yahoo in the last 2 years – where he strongly advised the use of JSON for encapsulating data. Now I understand why…)

Of course, you can clone that pipe and start your own development out of it. I’m really curious what can we start from here. Disclaimer: this is intended as a pure exercise and can change in time. Or at least I do hope it will change in time .

Happy piping .

[tags]gtd, yahoo pipes, mashups[/tags]

Personal and Software development: Paid model vs Open Source model

My last try to write about something related to OS’s was somehow a flamer on digg. Myabe I haven’t stated enough during the article that I was only interested in listening to opinions from the guys that actually switched from one OS to another, and that I didn’t try make any comparison between those two OS’s. So, if I would like to talk about something far more inflamable thant that, meaning paid model development vs open source model development, I thought I’d better put up first a

Disclaimer

This article represents my personal opinions only and is not endorsed by any company or foundation. Also, my intentions is, foremost, to just express my ideas about the values that each model could have, and not to accuse, adhere to or specifically endorse any of them.

Wow, it’s cool to be relaxed, so let’s start our little walk on the park of the personal and software development.

First of all, yest, it’s an odd pair: personal and software development. But I told you from the beginning: you wouldn’t find usual stuff here. Not because usual is not good, but because new connections and standpoints can always shed some new light and reveal new thinking paths on any topic you can imagine.

(more…)

MAC OS X – Quicksilver: instantly create text files and prepend or append text to them

Suppose you are in the middle of something, reading a post on a blog, or writing a fine article in your editor of choice, or even writing some code for your ground breaking web 2.0 application. And ka-boum: you have an idea! Something so interesting, so juicy and fun to think about crosses your mind, than you feel you can’t live anymore until you actually write down that piece of thought. Somewhere, somehow. So there you go:

1. leave your current activity/application
2. open Finder (or some other program menu containing an outliner application shortcut, for instance)
3. open that outliner application
4. open a new file in it
5. start writing the marvelous idea
6. hit save as menu item
7. chose location and save
8. close the outliner application
9. return to your current activity/application

But here’s how it would look like, if you would use Quicksilver:

1. type CTRL + spacebar to invoke Quicksilver window (while having the current activity/application still in front of you)
2. type “.” and start writing your marvelous idea
3. hit TAB and type “cre..” meaning the first letters of your “Create file” action of Quicksilver, and then enter (this really counts like a single action)
4. chose location and save
5. hit escape to hide Quicksilver window

Huh! We are four steps shorter than the original approach. That counts for less physical work, and less time, almost half, right? Nice, isn’t it? But that’s not the only advantage: you actually remain in the flow, while your thoughts are free to fly. Isn’t that really nice?

So, how we actually do that?

(more…)

Automating Photo Booth and iPhoto

You know all those strange albums on Flickr or those psychedelic movies on YouTube when a guy took pictures of himself for a year, each day? Or for two or three? Each day, another picture of himself? Well, although in the beginning the idea seemed a little creepy to me, I soon started to see, well, some benefits… Needles to say that, in a more adventurous state then ever, and with little forseen reward, I started my own “A Photo Every Day” project. Just for fun, if you want. Or just to see how often I need to shave. Or just to test my iSight’s capabilities. If that little ting could do a photo every day it worth every penny, right?

But in less than five days, after being warned daily by a plethora of reminders that I put on my desktop (and in my GTD system, of course), I saw that I spent around 2 minutes for each photo. Start Photo Booth, take the pictures, start iPhoto, import that photo, rename that foto… The funny thing with these projects are the big numbers behind them. For a week, 2 minutes every day counts as what, 10 minutes? But for 365 days, that will bring us 730 minutes, or at least 12 hours. Hmmm, maybe I could use those hours in a more clever way? And still have that project running?

(more…)