Atlas - Cappuccino/Objective-J dev environment

Atlas helps you focus on what's unique about your application, whether you're targeting the Desktop, the Web, or both.

• Runs in a browser
• Includes a design surface
• Has some novel UI for hooking up databindings
• They also show off a handful of components that they wire up to do things like “read an RSS feed”.

Link and download.

What is Behavior Driven Develpoment ?

Behavior Driven Management strives to ensure that all the people in the software chain, including developers, QE, analysts, and product management all speak the same language. There have been a number of efforts in this direction, taking it forward from TestDrivenDevelopment and AcceptanceTestDrivenPlanning. Read more at this link.

BDD relies on the use of a very specific (and small) vocabulary to minimise miscommunication and to ensure that everyone – the business, developers, testers, analysts and managers – are not only on the same page but using the same words. For people familiar with the concept of DomainDrivenDesign, you could consider BDD to be a UbiquitousLanguage for software development.
It must be stressed that BDD is a rephrasing of existing good practice, it is not a radically new departure. Its aim is to bring together existing, well-established techniques under a common banner and with a consistent and unambiguous terminology. BDD is very much focused on “Getting the words right” and this focus is intended to produce a vocabulary that is accurate, accessible, descriptive and consistent.
In fact “Getting the words right” was the starting point for the development of BDD, and is still very much at its core, but the power of getting the words right has led to some insights and extrapolations that have helped us to better understand our approach and to extend it.

MiniBuilder - Flash-based IDE for ActionScript development

A web based tool for Action Script development, available on code.google.com

Available at this site (link)

From this site:

Flash MiniBuilder is a lightweight IDE created for developing programs written in ActionScript 3.
Flash MiniBuilder is itself written in ActionScript
Two of the main raison d'etre of MiniBuilder are
1. provide a completely free and cross platform alternative for developing ActionScript projects.
2. provide an editor with a small footprint that would eventually run on smaller computers like netbooks or even pocket-size devices.
Extending, changing (and even integrating MiniBuilder with other software) is easy: MiniBuilder is itself written in your favourite language, AS3

Quick tip: What is Abstraction and how to do effective modular design ?

Abstraction is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics. Through the process of abstraction, a programmer hides all but the relevant data about an object in order to reduce complexity and increase efficiency. In the process of abstraction, the programmer tries to ensure that the entity is named in a manner that will make sense and that it will have all the relevant aspects included and none of the extraneous ones.

Effective Modular Design

Information hiding:
Modules should be specified and designed so that the internal details of modules should be invisible or inaccessible to other modules. Hiding implies that effective modularity can be achieved by defining a set of independent modules that communicate with one another only that information necessary to achieve software function. Hiding defines and enforces access constraints to both procedural detail within a module and any local data structure used by the module.

Major benefits: Reduces the change impacts in testing and maintenance.

Product Development - Getting requirements and prioritization - Part 2

The previous post talked about how the Product Management team generated requirements for the new version of the product. When this happens, the next most important task is to get an idea about how much effort getting all these requirements into the product will take. This is easier said than done. Doing effort estimation when the requirement is a stated 2 line statement can be really difficult, and requires some amount of refinement.
What would next happen in most cycles that I have seen is that the requirements are next discussed between the Product Management team and the engineering team (typically senior engineers along with the engineering manager); this process also envisages that the requirements are discussed to some extent in terms of what the workflow would be (keep in mind that this is not the right time of the cycle to start designing screens or dialogs or detailing the workflow other than a top level attempt - doing such an effort for most requirements would take too long and is difficult to attempt).
What really helps for this effort is to use some sort of documentation (I know people who use Word or use an internal Twiki implementation, or some other tool to capture such requirements in a medium level of detail (this is somewhat tricky, you need to have enough detail that you can take a rough guess at the effort estimate), and where you can break down the top level requirements into one step lower of requirements (example, if you need to add a new editing capability to a tool, the intermediate level requirements could be about having different file formats supported, or about different levels of editing such as having 3 quick buttons, or a slider to allow the user to have more control)).
Another element of this cycle is to press for prioritizing the requirements. It is incredibly important to make sure that prioritization is done, and there is a possibility that the product management team may have some hesitation in terms of doing the prioritization of these requirements. However, given my earlier statement about resourcing not being infinite for the product development cycle, setting a priority means that the team can focus on those requirements that are most critical, and then on the ones that are deemed less critical. The other advantage of forcing the priority is that this process forces the product management team to take a deep look at the features (including sub-features) in terms of whether this is something that will really benefit the product. This also ensures that resources are spent wisely.

Product Development - Getting requirements and prioritization - Part 1

I have in mind a series of posts that explains how the product development process works inside one of the teams for a product development company (based on previous experiences). However, this story has been interrupted in the past, and I believe I last posted on this topic many months back. I will try to be more regular on this topic in the future. Previous topics that I had written about were pre-release planning and metrics.
This topic will be about the meat of actually starting work on new feature development; the need is to actually define what the team needs to deliver in this new cycle. At this stage in the cycle, the only known facts are:
- It is decided that a new version will be required
- Dates are typically known for the release. Dates can be decided based on having to schedule for a certain condition of the market (in the US, to meet the enhanced marked season starting from Black Friday to Christmas, product development needs to conclude by a certain time so that the product can make its way through the retail chain and into the hands of retailers, large and small); dates can also be scheduled to meet projected customer needs (so if a software / hardware producer faces rivalry from Apple, it used to be that they would schedule release near MacWorld to prevent Apple from running away with the market)
- The number of resources are typically known. For most product development situations (unless there is the need to scale up to meet a competitor), the resources are not changed based on the number of features available. What would happen is that the features that can be implemented are decided based on the number of resources available.

So what happens next ? Well, what needs to happen next is that the product management team needs to decide on the features that are sought to be included in this release. If the product is something large such as the next version of Visual Studio C#, then the product management team would normally comprise of multiple product managers, each of whom would be tasked with a different area of the product. It is part of the responsibility of the product management team to decide on the features that are part of the consideration set for the release (and sources for new features include competitor analysis, user requests through forums, changes suggested through usability studies and through group sessions; there are also features that may correspond to changes in the market but not suggested by users - as an example, consider the case when a new technology related to online technologies hits the market and the product needs to have features to integrate with these new technologies or features - as an example, with the emergence of social networks such as Twitter, Facebook, MySpace, it may be needed for products to see how they would integrate with those).
So ends Part 1 of this post, I will carry it ahead with the next post.

PhoneGap

PhoneGap is an open source development tool for building fast, easy mobile apps with JavaScript.

If you’re a web developer who wants to build mobile applications in HTML and JavaScript while still taking advantage of the core features in the iPhone, Android and Blackberry SDKs, PhoneGap is for you.

PhoneGap Creators
Rob Ellis, Creator, JavaScript Maintainer

Rob is a developer at Nitobi Inc. As one of the PhoneGap creators, Rob is focused on trying to make mobile device app development easy and open. At Nitobi, Rob is part of a team that makes web applications easier to use by building software that allows both developers and end-users be more effective.

Brock Whitten, Creator, iPhone Maintainer and Repo Maintainer

Brock is a software developer at Nitobi Inc. He is one of the brains behind PhoneGap and recently presented on PhoneGap at MobileCamp Vancouver. Brock wants to see developers get really creative now that the barrier of entry for developing on mobile devices is getting increasingly lower.


If you want to read more, click this link.

Rapid Environment Editor

Rapid Environment Editor (RapidEE) is an environment variables editor. It includes easy to use GUI and replaces small and inconvenient Windows edit box. RapidEE 3.x supports Windows NT, 2000, XP & Vista. If you still use Windows 9x or ME, then use 2.x branch.

Editable tree
Show environment variables and values as an editable tree. Click the thumbnail to view the full size image

Multilanguage interface
RapidEE is translated into number of languages (English, Russian, Japanese, French, Polish, German, Italian, Latvian, Slovak, Greek, Spanish, Chinese), and the language can be changed on the fly.

Variable inspector
Inspector shows miscellaneous information about variables: name, type, value, short file name in the 8.3 naming convention for each long file name and vice versa.

More details and download at this link.