Archive | Web Development RSS feed for this section

Extreme Programming Review

15 Aug

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

8 Aug

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.

Rails 3 Screencasts

5 Aug

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 DispatchBundler & Action MailerActive Relation & Active Model,  Cross-site scripting & Unobtrusive JSThe New Action Controller.  Here’s the introduction video to get your appetite wet.

Agile Toolkit

31 Jul

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.

Beautiful Markup

31 Jul

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.

Review: Practices of an Agile Developer

18 Jul

Mind Map: Practices of an Agile DeveloperRecently 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.

I Have No Talent

27 Jun

by John from RailsTips:

The other day someone sent me an IM and thanked me for my open source contributions. They then said something about wishing they had my gem/code creation talents. I didn’t miss a beat and informed them that I have no talent.

It is true. I have no talent. What I do have is a lot of practice. And I am not talking about occasionally dabbling in Ruby on the weekends. I am talking about the kind of practice where I beat code that isn’t working into submission (though often times the code wins).

The kind of practice where all of a sudden I realize that it is 2am and I’m exhausted physically so I should go to bed, but mentally I feel on fire so I let the code have me for another hour or two (I imagine this state to be like a marathon runner or ironman near the end of their race).

The kind of practice that leads to a GitHub profile stuffed with code I regret (and am embarrassed about, but don’t delete to remind me of where I once was) and code I am proud of (not near as much as I am embarrassed about though).

Intelligence

I am also not very smart. I have a good memory (though my wife will tell you it has some missing pieces) and I work really hard. Really hard. I get that from my dad. He is also not very smart (his words, not mine), with a good memory and works really hard. :)

I am sick of hearing people say, “Oh, I love your code, I wish I could do that.” You can. The only reason you can’t is because you don’t practice enough. I used to think that I wasn’t smart enough. I was jealous of those that did crazy code stuff that I couldn’t even comprehend. Then, one day, I ran into something I did not understand and instead of giving up, I pushed through. I sat there in front of my computer for hours and wrestled with class and class instance variables.

That day was a turning point for me. It was the last time I thought that whether or not I was successful depended on my talent or intelligence. It really comes down to hard work people. Ever since then, I have attacked each thing that I do not understand until I understand it.

I will close with this. I still suck. There are still so many people out there who are far better than I am, but that does not stop me anymore. I do not measure myself against the programming greats, but against those projects on my Github profile from years ago.

How do you turn inspiration into skill?

27 Jun

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.