Hamid

XP is a discipline of the business of software development that focuses the whole team on common, reachable goals. XP teams develop and produce quality software at a sustainable pace.

XP brings accountability and transparency to software development.

XP provides different practices to software development team to improve their performance and quality, following are some of the practices introduced by XP:

– Testing early, often and automated: Unit testing
– Incremental design: design everyday
– Daily deployment
– Customer involvement: immediate feedback
– Refactoring
– Continuous integration
– Short development cycles
– Incremental planning

Using above practices day-to-day help us to reduce our development stress and improve our development quality.

Practices are evidence of values, values such as communication, simplicity, feedback, courage, respect, as well as other values like quality-of-life, safety, security and predictability. XP embrace these values.

There are principles that guide XP. It follows principles to build a bridge between values and practices. Principles based on humanity, economics, mutual benefits, self-similarity, improvement, diversity, reflection, flow, opportunity, redundancy, failure, quality, baby steps, and responsibility.

We use the principles to understand the practices better and to improvise complementary practices. Understanding the principles gives you the opportunity to create practices that work in harmony with your existing practices and your overall goals.

XP became to make life better for programmers.

Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development,it advocates frequent “releases” in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.

Other elements of extreme programming include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, simplicity and clarity in code, expecting changes in the customer’s requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to “extreme” levels, on the theory that if some is good, more is better. It is unrelated to “cowboy coding”, which is more free-form and unplanned. It does not advocate “death march” work schedules, but instead working at a sustainable pace.

Critics have noted several potential drawbacks, including problems with unstable requirements, no documented compromises of user conflicts, and lack of an overall design specification or document.

by Gregg Pollack – Envy Labs

At Railsconf I announced the release of the Rails 3 screencasts I’ve been working on for the past few months.  Here at Railsconf Envy Labs ran a three hour Rails 3 tutorial (which received fantastic feedback).  These screencasts basically cover the same content we presented in the tutorial (without the labs).

There are six different videos which are all published on the official RubyOnRails.org website.  There’s a two minute Introduction video,  Getting Started & Action Dispatch, Bundler & Action Mailer, Active Relation & Active Model,  Cross-site scripting & Unobtrusive JS, The New Action Controller.  Here’s the introduction video to get your appetite wet.

An Agile developer needs a bunch of tools that support agile projects, following is a list of vital tools for every agile project:

1. Text Editor
2. Source Code Control System (Version Control)
3. Project Management and Tracking System
4. Unit Testing (Test Driven Development)
5. Continuous Integration
6. Deployment Automation (Build Automation)
7. Wiki

For more details please refer to Practices of an Agile Developer and Pragmatic Programmer books.

by Gregg Pollack

One of the best talks at Railsconf was given by John Athayde on Curing Div-itis with Semantic Html, CSS, and Presenters. John was nice enough to redo his talk for me at the conference so I could properly capture it and share it with you. In his talk he goes through several techniques they employ at InfoEther to create beautiful markup in their web applications.

Recently I read ‘Practices of an Agile Developer’ book by Venkat Subramaniam and Andy Hunt, in this book we read a lot of practices, ideas, and approaches of successful agile software developers and the book presents them in a series of short, easy-to-digest tips. It covers following topics and this picture shows mind-map of the book:

– Agile Software Development

– Agile Manifesto

– Agile Toolkit

– Outcome over process idea

– Feeding Agility

– Brown-Bag sessions

– Invest in your team and how to keep up-to-date

– Learn and unlearn

– Track issue

– Design and business analysis

– Deployment automation

– Releasable code

– Continuous Integration

– CRC cards

– Iteration and incremental development

– Agile feedback

– Agile design and business analysis

– Backlog technique

– Measure progress

– Scrum sprints

– Importance of feedback by team, code, and user

– Unit testing and T.D.D

– Encapsulation

– Elegant Code

– Commenting

– Inheritance and delegation

– Agile debugging

– Exception handling

– Solution logs

– Prototype

– Project sharing

– Stand up meeting

– Information radiator

– Rescue a failing project

It is a great book and I highly recommend it for developers, project managers, and IT professionals.

by Ryan from 37Signals.com

Over the last few months I’ve noticed a ton of inspiring websites. Camerion.io, Art Lebedev, n+1, Show of Force, and on and on. And everytime I look at one of these sites, I think to myself “Oh I’m so inspired. Look at how they did this. Look at that paragraph style. Look at that header. I feel so full of ideas.”

Then it’s time to work on a new project, and did all the inspiration make a difference? Actually, no. Most of the work I do is looking like all the other work I’ve done for months and months and years. Apparently looking at cool stuff isn’t enough to increase your skill. It’s easy to look at some stuff and say “oh that’s inspiring, that gives me ideas” without moving an inch.

So I got thinking. How did I develop the basic skills I have right now? Mostly by copying heroes. When you’re fresh starting out, you have no fear of diving in and copying something directly. It’s like playing guitar. When you start playing guitar all you want to do is play the first verse of your favorite song. Big success! You don’t need to write the next great guitar symphony or a hit single. It’s totally satisfying to learn to play something somebody else can already play. And you get better by doing it.

And it was the same way with design. I was totally psyched to copy a Müller-Brockmann poster, a Designgraphik composition, or an Apple UI. Merely executing the copy was a thrill. But now every design is supposed to be the next great thing. And as days and weeks and months go by, the design level stays the same while the aspiration goes higher and higher.

So maybe it’s time to take one of these Fridays off and just copy something.