The changes to WordPress in 2.5 and 2.7 were necessary to break free of much of the legacy cruft and interface bloat that had built up over the years (gradually) and more importantly to create a UI framework and interface language that will be the foundation to build tomorrow’s WordPress on. So at the end of 2009 I expect, interface-wise, WordPress to look largely the same as it does now.

This means that you should jump in now and take the effort of the upgrade, especially if you’re still using 2.3 or an older release. You’ll get great security improvements, a ton of new features that have been added in both 2.5 and 2.6 releases, and a couple great new additions that will enable you to be fully independent in plug-in installations and core upgrades: infact this may be the last time you ever have to manually upgrade WordPress again.

WordPress’ Blog says: “We heard how tired you were of doing upgrades for yourself and your friends, so now WordPress includes a built-in upgrade that will automatically notify you of new releases, and when you’re ready it will download them, install them, and upgrade your blog with a single click.”

Clearly, some wisdom is always necessary when dealing with software updates: you shouldn’t upgrade immediately after a new release comes out, rather wait a couple of weeks, Google for the version number and read if people is having issues with it, and only then you should trigger the automatic upgrade process (after a full back-up of your website and database).

All other new features are subtly sprinkled through the new interface. Here are some:

• The new dashboard that you can arrange with drag and drop to put the things most important to you on top
• QuickPress,
• Comment threading, paging, and the ability to reply to comments from your dashboard,
• The ability to install any plugin directly from WordPress.org with a single click,
• Sticky posts,
• every screen is customizable: let’s say you never care about author on your post listings — just click “Screen Options” and uncheck it and it’s instantly gone from the page. The same for any module on the dashboard or write screen.

For a visual introduction to what 2.7 is, check out this video (available in HD, and full screen):

Read this entry on Surgeworks.com blog.

You’d have to style your segment controls programatically through the tintColor property. Now isn’t that annoying? 

The main drawback is that when they’re black, there’s no “darker” color of black. So all the segments are the same color. What you can do is imagine how it would look. Then go and make your segmented control dark gray.

We’re placing segmented controls on translucent navigation bars. I’ve read on a forum that setting [UIColor clearColor] for the tint should work, but haven’t test it yet.

Our scrum master for the latest iPhone App we’re working on decided we owe him 20 push-ups for being late at stand-ups. That came in handy, I thought, because I could use some physical workout… but what actually happened is that a joke came to my mind…

So far, my personal take is that the idea of a punishment and the mood scrum techniques put you in while working on a project are enough to keep you focused and make you give 110% to get your tasks completed for the next stand-up meeting. I realize that might not be the case for everyone…

What punishments are used in other scrum environments?  What penalties do you employ?

Meanwhile, if your scrum master has opted for the 20 push-ups penalty, feel free to forward him this joke

The typical scenario in traditional development is that people expect the space shuttle for 1000$. An evolution of this scenario in agile is that people expect to get to the moon in one iteration. With all the buzz around agile, people think that you can get a fully custom web app in a matter of weeks, polished and ready to launch, in one “sprint“.

Well, that is usually not the case. You can get a usable product in one sprint, prioritize features, and get to the market in less time with a nice product. But you can’t expect that all aspects, features and requirements are met in the first version of the product, especially if it’s a feature reach web application or a hosted service.

Recent web apps history has taught us that “less is more”. That is very true so keep it in mind when you envision your product. You can have a ton of features in your backlog but you don’t need to wait until all your vision is implemented into the code before launching your product. Prioritizing features does not mean that “some will get there in sprint 1, some in the following” — it means some features won’t make it to the final product.

A nice quote about this is that 50% of the features that are implemented at 100% are a success, while 100% of the features at 50% are a failure. This won’t make your product less attractive, it’ll make it more focused and specialized, easier to use for early adopters and will leave space for growth with faster return of your investment while keeping all within your budget.

The worst scenario though, is when people don’t have clear goals. I’m not referring to requirements, we’re used to work with very little written requirements and even those are not carved in stone. I’m referring to what you want to achieve with your product. If you don’t have a clear target, a clear vision, or at the very least a clear need you want to satisfy — then that is a real issue for us.

Changing your requirements to meet your goals is manageable, because you, the project manager and usually most of the developers involved (the “pigs“) get the big picture and can help and foresee those changes, or even propose some themselves. Changing your goals when the product is on its way means changing the big picture, and the risk is it’ll disrupt the “symphony” between all team players, demotivate the developers and make it a really difficult project to manage.

This concept transfers well to the scrum attitude, which, as Carl Youngblood once said, one could basically sum up as an acknowledgement that human beings can only focus on their goals in small steps and for short periods of time and need help from one another, ways of visualizing their progress, and constant reassessment to be successful.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach – accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.

Following are some general practices of Scrum:

• Customers become a part of the development team. (i.e. the customer must be genuinely interested in the output.)
• Like all other forms of agile software processes, Scrum has frequent intermediate deliveries with working functionality. This enables the customer to get working software earlier and enables the project to change its requirements according to changing needs.
• Frequent risk and mitigation plans developed by the development team itself. – Risk Mitigation, Monitoring and Management (risk analysis) at every stage and with commitment.
• Transparency in planning and module development – Let everyone know who is accountable for what and by when.
• Frequent stakeholder meetings to monitor progress – Balanced (Delivery, Customer, Employee, Process) Dashboard updates – Stakeholders’ update – You have to have Advance Warning Mechanism, i.e. visibility to potential slippage / deviation ahead of time.
• No problems are swept under the carpet. No one is penalized for recognizing or describing any unforeseen problem.
• Workplaces and working hours must be energized. – “Working more hours” does not necessarily mean “producing more output.”

Several roles are defined in Scrum; these are divided into two groups; pigs and chickens, based on a joke about a pig and a chicken.

A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed but you’d only be involved.”

So the pigs are committed to building software regularly and frequently, while everyone else is a chicken: interested in the project but really irrelevant because if it fails they’re not a pig, that is they weren’t the ones that committed to doing it. The needs, desires, ideas and influences of the chicken roles are taken into account, but not in any way letting it affect or distort or get in the way of the actual Scrum project.

In scrum, a project begins by conducting a meeting in which the features of the application to be developed are determined.  The resulting document is called product backlog which is a high-level document for the entire project. It contains broad descriptions of all required features, wish-list items, etc. It is the “What” that will be built. It is open and editable by anyone. It contains rough estimates, usually in days. This estimate helps the Product Owner to gauge the timeline and, to a limited extent, priority (e.g. if “add spellcheck” feature is estimated at 3 days vs 3 months, that may affect the Product Owner’s desire).

The sprint backlog is a greatly detailed document containing information about how the team is going to implement the requirements for the upcoming sprint. Tasks are broken down into hours with no task being more than 16 hours. If a task is greater than 16 hours, it should be broken down further. Tasks on the sprint backlog are never assigned, rather tasks are signed-up for by the team members as they like.

Each day during the sprint, a project status meeting occurs. This is called ”the standup meeting“. The scrum has specific guidelines:

• The meeting starts precisely on time. Often there are team-decided punishments for tardiness (e.g. money, push-ups, hanging a rubber chicken around your neck)
• All are welcome, but only “pigs” may speak
• The meeting is timeboxed at 15 minutes regardless of the team’s size.
• All attendees should stand (it helps to keep meeting short)
• The meeting should happen at the same location and same time every day

During the meeting, each team member answers three questions:

• What have you done since yesterday?
• What are you planning to do by today?
• Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to remember these impediments.)

At the end of a sprint cycle (every 15-30 days) a sprint retrospective is held, at which all team members reflect about the past sprint. The purpose of the retrospective is to make continuous process improvement. This meeting is timeboxed at four hours. Two main questions are asked in the sprint retrospective:^[1]

• What went well during the sprint?
• What could be improved in the next sprint?

Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project.

Read more about SCRUM on Wikipedia

I also had a chance to use it to record a 1 hour long theatre spectacle coming out of a Berhinger analog mixer and it’s been fully reliable — and it’s really affordable too.

This ultra-compact FireWire audio interface is an ideal companion for laptop musicians and ingeniously complements any studio. Its hot features include: Two ¼” connector inputs and outputs for connecting synthesizers, mixers and more; high resolution 24-bit A/D and D/A converters offer 96 kHz sampling frequency; volume-controlled headphones for discreetly working on your compositions, even on the road. Mac OS X Core Audio drivers guarantee low latencies.

With the ultra-stable metal construction, the FCA202 easily defies the adversities of travel. And its small dimensions make it an ideal solution for laptop recording. Additional features include two 6-pin FireWire connectors, a security port for Kensington locks and the possibility to power the FCA202 via FireWire or a mains adapter, which is included. The hot FCA202 package also comes with the coolest sequencing software for mobile music production: the BEHRINGER Edition of Ableton Live Lite 4. Kristal and Audacity are also included and will empower you to face any recording challenge.

What strikes me more is the fact that FireWire is perceived mostly as a mean to transfer video from digital camcorders rather than a fully bloated SCSI replacement. FireWire is not just about video… Hard Disks and Audio peripheral truly benefit from this standard that is far superior to USB 2.0. Unfortunately, money drives the market and USB 2.0 is a cheaper standard to implement both technically and on the licensing side of things.

Apple invented the standard in the late 80s as a hot pluggable replacement for SCSI, with a special emphasis on supporting media streaming with isochronous, real-time data transfers. Upon returning to Apple in 1997, Jobs hoped to earn some licensing royalties from the technology, which was quickly becoming an emerging standard not just to replace SCSI but also in video and music applications. Jobs’ plan resulted in Intel offering to upgrade its USB standard to speeds approaching FireWire at a lower cost.

Somewhat ironically, Apple’s 1998 iMac originated the push behind USB (due to the lack of any FireWire support in both the first generation iMac and iBook!) that allowed it to gain rapid adoption among consumers. USB 2.0 built upon that ubiquity to push into the peripheral territory that had been wholly owned by FireWire.

While USB 2.0 ate into the casual peripheral market for consumer hard drives and web cams, FireWire retracted to support applications where USB 2.0 wasn’t suitable. The future of FireWire is still not written. 

However — a little sadly particularly because I just bought a FireWire Audio Interface from Behringer – I think that FireWire is not going to last long on MacBook Pro, Mac Pro, or iMac, either.

• What keyword density % people are using for site SEO?
• Submitting articles and SEO
• Why do companies blog?

About keyword density in blog posts:

“I have run reports on sites which usually bear around a 1-2% density for the primary keywords. This means that a specific term is repeated 3-6 times in 300 words of copy.”

“The short answer is: If your keyword density is close to hitting 5%, then you’ve definitely got too many keywords in there.”

“… as a general rule, you don’t need to be above 5-7%. Anything above that is certainly unnecessary.”

“Users today are becoming selective in the search patterns. Many rely on phases or “direct usage” to filter out the non-sense results that have little or no value to the search request. Hence the beauty of a blog, writing a column filled w/ keywords and links to seperate pages can sometimes answer most of the questions.”

About submitting articles, syndication and content duplicates being recognized by search engines:

“The consensus is that yes, dupe content can be detected but it is rarely penalized. Particularly if you are using article directories. [...] As long as you are using legitimate sites, you don’t have any problems. Of course, if you really want to be certain – post an information rich press release to your blog. Use a different press release for submission to the syndication sites, and reference the blog post in that press release. That will give you a far better search engine. “

“Start by sharing your articles with 2 or 3 sites. If they’re working effectively (i.e. you’re getting more visitors and leads to your site), then stop there. If not, try 2 or 3 more sites. It’s often a waste of time to submit your article to every site you know about. If the directory doesn’t look or feel legitimate, or has a low Page Rank, don’t use it. If it looks like spam to you, then it probably looks like spam to Google.”

And finally, here’s why companies (should) blog…

“What blogs do that the other tools do not is tell a story and invite participation – in the age of participation a blog has been one of the cornerstones of this evolution in digital messaging. Blogs can show the personality of an organisation, its culture, thinking etc… A blog creates a dialogue between the audience and the author. The dialogue builds a relationship.”

“The concepts of social networking and viral marketing are exciting and the benefits have yet to be fully understood or even measured. Yet everyone concludes they are incredibly powerful and can suddenly steer markets. Blogging may have been an early form of viral marketing.”

“[...] the point of blogging [...] is connecting your company and your brand with customers in a less plastic, pabulum-based manner. People want to deal with humans on a company blog, not faceless regurgitation of press releases.”

Original discussions can be found here:

• Curious what keyword density % people are using for site SEO?
• Submitting articles and SEO
• Why do companies blog?