Home › ›

When to use helpers for generating javascript

Submitted by tbatucan on Mon, 09/15/2008 - 10:29

A practice that I've started doing more of in my Rails application has been using a helper to generate javascript to remove duplication and magic numbers or strings. Primarily the only time I've generated javascript is when I needed to generate the url for an Ajax request or something similar using the url_for{:controller=>'foo', :action=>'bar'}. In the past, most of my javascript was placed in a static javascript file in the javascript library. One of the justifications for this of course is to allow the browser to cache the javascript file.

Feedback: Don’t forget about the testing team

Submitted by bfoster on Tue, 09/09/2008 - 13:57

Software development companies started to adopt the principles of Extreme Programming and Agile Development to help reduce risk in a world where change is inevitable. To help adapt to this inevitable change, agile principles call upon feedback and a lot of it. Many people understand the importance of customer feedback (advice during requirements meetings, user acceptance testing, etc…) and unit tests, which gives developers instant feedback several times a day. An equally important source of feedback comes from the testing team who can provide quick, quality feedback.

Team Design: Building Better Software

Submitted by psavage on Sun, 08/31/2008 - 21:43

Collective Code Ownership is an important practice of Extreme Programming and team design is an essential part of it. Whether the design is done individually or collectively can significantly affect the performance of the team and the quality of the code. Team design helps build software that all of the developers understand and can effectively build upon.

Facilitating Team Communication

Submitted by bwalsh on Thu, 08/21/2008 - 09:43

In almost every aspect of our lives poor communication is often the root cause of problems that result in misunderstandings and inconsistent expectations. Software development teams comprised of multiple individuals, many with other responsibilities who are working part time on a project, are no exception to being prone to communication issues. Numerous studies, such as a web survey in March 2007 by the Computing Technology Industry Association, single out poor communications as the number one cause of project failure.

Staying Focused and Slashing Feedback Sure Ways to Get Productive

Submitted by ddewolf on Sun, 07/20/2008 - 22:03

What is the key to a seamless thought process? Take control of your committed development time. It’s no surprise that anyone will increase productivity by reducing distractions. And what’s the major difference between average developers and those who really stand out? In a word: productivity. Developers who excel have learned to get the most out of their coding time. They’ve mastered techniques enabling them to continuously focus on delivering working software.

Simple design: The Best Way to Beat Bloat

Submitted by ddewolf on Sun, 07/13/2008 - 22:17

One of the principal values of Agile Software Development is the priority given to working software. Agile development teams value working code over documentation, complex architectures, and other extraneous artifacts. This does not mean that Agile teams disregard these artifacts; it only means that they value working software more.

While the value of working software translates into many design and development practices, none may provide a more significant productivity boost than the practice of “Simple Design”. Whether you work in an agile or more traditional environment, simple design can be key to giving your team a major productivity boost.

Take a Stand for Codebase Standardization

Submitted by ddewolf on Sun, 07/06/2008 - 22:19

Same line or next line? Tabs or spaces? Camel case, underscores, or dashes? Whether the debate is code conventions or naming standards most developers have their preference. And even if you don’t, you probably recognize these questions as falling under one of the most religious topics in software development.

Like most developers, I have my preference regarding conventions. I want my opening brackets on the same line. My file names? I can’t stand upper case letters, so give me dash separated JSP files. As for tabs, forget it. Spaces are undoubtedly the way to go. While these are my preferences, I have one that’s even more important: standardization.

The Psychology of Builds

Submitted by ddewolf on Fri, 06/27/2008 - 22:16

Build times matter. Agile development and other pragmatic methodologies rely heavily on the practices of continuous integration, automated testing, and frequent builds. As build times grow, it becomes increasingly difficult to maintain the frequent use of these practices.

Automated builds must meet the restrictions imposed by natural psychological limits in order to serve their purpose. A build that is intended to be run during test driven development cycles must execute quickly so as to not interrupt the flow of development. A build supporting a pre-check-in smoke test that hangs mercilessly for ten minutes will discourage the exact practice it is intended to support. Build systems must be designed to meet their purpose.

Syndicate content