Slashdot Mirror

mikeatTB shares an article from TechRepublic: Software engineers have largely failed at security. Even with the move toward more agile development and DevOps, vulnerabilities continue to take off... Things have been this way for decades, but the status quo might soon be rocked as software takes an increasingly starring role in an expanding range of products whose failure could result in bodily harm and even death. Anything less than such a threat might not be able to budge software engineers into taking greater security precautions. While agile and DevOps are belatedly taking on the problems of creating secure software, the original Agile Manifesto did not acknowledge the threat of vulnerabilities as a problem, but focused on "working software [as] the primary measure of progress..."

"People are doing exactly what they are being incentivized to do," says Joshua Corman, director of the Cyber Statecraft Initiative for the Atlantic Council and a founder of the Rugged Manifesto, a riff on the original Agile Manifesto with a skew toward security. "There is no software liability and there is no standard of care or 'building code' for software, so as a result, there are security holes in your [products] that are allowing attackers to compromise you over and over." Instead, almost every software program comes with a disclaimer to dodge liability for issues caused by the software. End-User License Agreements (EULAs) have been the primary way that software makers have escaped liability for vulnerabilities for the past three decades. Experts see that changing, however.
The article suggests incentives for security should be built into the development process -- with one security professional warning that in the future, "legal precedent will likely result in companies absorbing the risk of open source code."

An anonymous reader writes: In an article titled "Scrum is dead: breaking down the new open development method," Ahmad Nassri writes: "Among the most 'oversold as a cure' methodologies introduced to business development teams today is Scrum, which is one of several agile approaches to software development and introduced as a way to streamline the process. Scrum has become something of an intractable method, complete with its own holy text, the Manifesto for Agile Software Development , and daily devotions (a.k.a., Scrum meetings). Although Scrum may have made more sense when it was being developed in the early '90s, much has changed over the years. Startups and businesses have work forces spread over many countries and time zones, making sharing offices more difficult for employees. As our workforce world evolves, our software development methods should evolve, too." What do you think? Is Scrum still a viable approach to software development, or is it time to make way for a different process?

snydeq writes "InfoWorld offers a look back at the first decade of agile programming. Forged in February 2001 when a group of developers convened in Utah to find an alternative to documentation-driven, 'heavyweight' software development practices, The Manifesto for Agile Software Development sought to promote processes that accommodate changing requirements, collaboration with customers, and delivery of software in short iterations. Fast-forward a decade, and agile software development is becoming increasingly commonplace, with software firms adopting agile offshoots such as Scrum, Extreme Programming, and Kanban — a trend some see benefiting software development overall."

Ridgelift writes "Learning to develop web applications with Ruby on Rails has gained a huge amount of interest lately, but for people wanting to learn Rails there are no books on the subject. That's changed now with the pre-release of Agile Web Development with Ruby on Rails , the latest book from Dave Thomas and the author of Ruby on Rails David Heinemeier Hansson. It's really 3 books in one: a full Rails tutorial, an in depth guide to the components that make up Rails, and an introduction to developing applications using the Agile development model. There's even a quick introduction to Ruby, the language Rails is built with." Read on for an early review of the beta book. Full disclosure: Reviewer Miles K. Forrest points out that he has read earlier versions of the book's manuscript and provided critiques to the authors. Agile Web Development with Ruby on Rails author Dave Thomas and David Heinemeier Hansson pages 506 publisher The Pragmatic Programmers, LLC rating Excellent reviewer Miles K. Forrest ISBN (Book still in beta) summary A complete primer to developing web applications with Ruby on Rails

At just over 500 pages, Dave Thomas' new book manages to cover a lot of ground in a concise, readable manner. One problem at the outset -- the book is not finished. Knowing that the Ruby on Rails community has been chomping at the bit for morsels of information, Dave and David (DHH) have answered the call by releasing the forthcoming book early. "The book has not had a full technical edit, so it will contain errors. It has not been copy edited, so it will be full of typos. And there's been no effort spent doing layout, so you'll find bad page breaks, over-long lines, incorrect hyphenations, and all the other ugly things that you wouldn't expect to see in a finished book. We can't be held liable if you follow our instructions, expecting to create a Rails application, and you end up with a strange shaped farm implement instead. Despite all this, we think you'll enjoy it!"

And enjoy it I did. The "Getting Started" section of AWDRoR provides a whirlwind overview of the Ruby on Rails' architecture. I found Rails to be very intimidating at first. You can't just cut-and-paste a couple lines of code like you can in PHP. Rails generates all kinds of directories and files, making it feel like your first trip to Disneyland -- you know there's fun to be had, but it's a big place and you don't know your way around. The reason for all this is because, in programming, short simple scripts are easy and simple, full blown Web applications are not. Many LAMP projects developing in perl/Python/PHP and any number of templating engines have started simple, but grown into unruly messes that are difficult to maintain. While trying to grok Ruby on Rails, topics like Model-View-Control and Object-Relational Mapping really don't stick at first. Add to the confusion that many of us are also struggling to learn Ruby and a RDBMS (such as MySQL; Rails works with others databases as well). The overview of Rails is necessary, but I found it to be a lot more helpful rereading it after completing the tutorial section. So if you read through this first section and feel lost like I was, just know that the material will become familiar to you and press on, because it gets a whole lot easier from here on in.

I really enjoyed the Tutorial section, a narrative designing a shopping cart application for a customer. Dave says it best: "Does the world need another shopping cart application? Nope, but that hasn't stopped hundreds of developers from writing one. Why should we be different? More seriously, it turns out that our shopping cart will illustrate many of the features of Rails development. We'll see how to create simple maintenance pages, link database tables, handle sessions, and create forms. Over the next seven chapters, we'll also touch on peripheral topics such as unit testing, security, and making our pages look nice."

Dave begins not with lofty design plans, but with a tool most real programmers use: napkin drawings. Many of us sit down over coffee with a customer and talk about what they need, sketching out ideas with paper and pencil, not some complex software planning tool. Each chapter in the tutorial section allows a story to unfold, where the customer works alongside the developer. Real life situations like changing direction or refactoring code are covered as each programming session is done. You really see why Rails is becoming so popular. It wasn't written by a team of programmers trying to hammer out an arbitrary list of features, but rather Rails was built around a real application (Basecamp). Pragmatic considerations such as developer time, feature creep, and maintenance issues have all been skillfully addressed in Rails. The tutorial reflects this, and at the same time it also gently, almost unknowingly, teaches principles as outlined in the agile manifesto. Some of the goals include:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

AWDRoR can get away with this because Rails itself was designed around the principles of Agile software development. The tutorial is probably the best I've ever read. You really come away from it knowing not only what you've written, but why, as well as picking up a few expert developer tips along the way.

The third section, "Rails in Depth," dives into the inner workings of Rails. Components such as ActiveRecord, ActionController, ActiveView, and Web Services (Ajax) are all covered well. There are even chapters on securing and deploying your applications properly. These chapters, in conjunction with the API docs found on www.rubyonrails.org, give a full overview of Rails. Most helpful in this section are the notes and diagrams which help pull everything together. The appendices that cap off the book also provide the full tutorial source code, as well as a brief introduction to Ruby, the language that makes all the magic happen.

In short, Rails is a brilliant architecture, and Agile Web Development with Ruby on Rails is a great book. I'm reluctant to point out its shortcomings as it's still in beta, but it's really hard for me to find much to complain about. It took me some time for the light to come on with Rails, but once it does, you see that Rails could not exist without Ruby, the language it's inextricably woven into. As Dave Thomas is quoted on www.rubyonrails.com, Rails is probably "the framework to break Ruby into the mainstream." Whether you believe the hype or not of "super productivity," "Ten times faster development," and "Better than anything else," Ruby on Rails is a great tool to add to your belt. In fact, I find myself using it exclusively for Web apps, and I catch myself using python and PHP less and less and Ruby more and more for my day to day programs.

If you want to learn Ruby on Rails, Agile Web Development with Ruby on Rails is a great choice, and will probably be the definitive book on the subject.

Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

James Edward Gray II writes "If you've ever wanted to know more about the agile programming methodologies, Integrating Agile Development in the Real World is a fine place to look for the answers to your questions. Various agile methodologies are explained, compared, and contrasted within. A good look is taken at how they work, their strengths and weaknesses, and how they compare to the more traditional approaches of software development. This proves to be a strong introduction and overview to agile programming practices." Read on for the rest of Gray's review. Integrating Agile Development in the Real World author Peter Schuh pages 346 publisher Charles River Media rating 8 reviewer James Edward Gray II ISBN 1584503645 summary An encyclopedia of agile software development practices.

The book opens with a couple of chapters exploring exactly what it means to be an agile development team. The author doesn't spoon feed you a definition. Instead, he takes a look at the Manifesto for Agile Software Development and pulls from that a collection of values important to agile software development. A list of agile principles is presented, and each of these aspects is examined from the angle of what it's trying to accomplish and where it can help when building software.

At this point, the book introduces seven methodologies including The Crystal Methodologies, eXtreme Programming, and Scrum. Each approach is defined by their practices and focus. The author does a nice job of telling you where these methodologies excel and even where they don't. The approaches are contrasted, but not with an eye towards finding out who is right and who is wrong. Instead, the author digs for the strengths in each practice.

The next few chapters offer suggestions about what agile practices can do for your development team, and outline how to adopt a few agile practices. This is one of the many places where the book really shines, thanks to its realistic approach. The author knows that not everyone can run out, soak up some eXtreme Programming training, and convert their entire division overnight. If you can, great, but this book is more focused on people who don't meet certain agile requirements and others who just want to test the waters a little. For these groups, there is sensible advice like, "Start by doing X, Y, and Z, because they're great ideas, easy to implement, and will help you a lot." If you like those changes, the author suggests what to try next. Even better, you're told to back away from the changes you don't like, sprinkle in some ideas from other methodologies, and even customize the practices to your needs. That may not be as extreme as some agile developers would prefer you to be, but it is agile programming distilled down to what it can do for you personally. I found that to be a great touch.

With the introduction to this new world of software development covered, the book moves into detailing actual agile practices. Early chapters in this section focus on the programmer, testing, and even the database side of the operation. Later chapters get into management, the project, and an agile development cycle. When a practice is defined, you're warned of prerequisites you should have in place before considering it, offered advice for how to get started with it, and even given a few variations that might work better for your group. I wouldn't say that the detail here is sufficient to teach you all you need to know, instead this section arms you with the knowledge to decide what you should be looking into. To kick-start your research efforts, a practice always ends with a list of further resources, available both online and in print.

The final chapters of the book get more abstract, dealing with customers, communication, and even just people. There's a lot of sound advice hidden away in these pages for some difficult challenges. I personally learned a lot about how agile development deals with customers and I have a few new ideas I'm anxious to try on my clients.

As an added bonus, the book has a very nice layout, filled with intelligent, witty prose and good looking charts. These effects are always subtle but can make a text a lot more approachable. I believe my only complaint was that the author tends to throw around acronyms assuming you know what they stand for. I think he even eventually got around to defining all but a couple, but not always when you first encounter them. A glossary probably could have helped in this case.

In summary, this book is agile programming for everyone. As a one-man operation, common practices like pair programming aren't even an option for me. The author knows that the methodologies aren't one-size-fits-all, and really focus on exactly what they can do for you, whatever your own needs may be. If you don't follow any development strategy (hope that's not true), would like to know more about the agile practices without joining a cult, or even just want to stay sane in your traditional software development company, Integrating Agile Development in the Real World will give you plenty of fresh ideas.

You can purchase Integrating Agile Development in the Real World from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

twelve71 (Alan Francis) writes "Apologies in advance for overuse of the word 'pragmatic,' but Dave Thomas and Andy Hunt together form a company called The Pragmatic Programmers, and published a book I'm sure many of you have read, titled The Pragmatic Programmer: from Journeyman to Master. The Pragmatic Programmer (or 'PragProg' as it is usually referred to) is a wonderful grab bag of 'good old common sense,' but its main strength (covering a very broad range of subjects) means that the authors have left a few holes around some important details. To plug some of these holes, and provide a good grounding for those just starting out, they have recently published 'The Pragmatic Starter Kit' - a set of books covering in detail some of the basics mentioned in PragProg." Read on for Alan's review of the latest book in the kit. Pragmatic Project Automation author Mike Clark pages http://www.pragmaticprogrammer.com/bookshelf/index.html publisher Pragmatic Bookshelf rating 9 reviewer Alan Francis ISBN 0974514039 summary Learn to use common, freely available tools to automate build, test, and release procedures.

The first 2 (or possibly 3) books are Pragmatic Version Control with CVS and Pragmatic Unit Testing (which is available in Java and .NET flavours).

Pragmatic Project Automation is the latest book in the series and, interestingly, this book wasn't actually written by either Dave Thomas or Andy Hunt, but by Mike Clark (contributor to the 'Bitter EJB' book, editor of the JUnit FAQ, and responsible for the JUnitPerf and JDepend tools). Mike does a great job of ensuring this book fits in with the overall style of the other books in the series.

Up front, in case you're a "cut to the chase kind of guy," this book (and the others in the series) are must-haves and as a consultant with ThoughtWorks I'll have a set ready to distribute whenever I start working with a new client team.

Content The book helps the reader build a Java project slowly over the chapters, starting with a manual build-and-deploy process and automating a new aspect of it, chapter by chapter, until by the end of the book the software compiles, archives, deploys and configures itself multiple times a day. In addition, the build tools notify you of success or failure in a variety of interesting ways including email, SMS messages and different colored lava lamps.

The first chapter provides a good introduction to the different types of automation available to projects. It also introduces the acronym 'CRISP' to help the reader remember the desirable characteristics of an ideal build process: Complete, Repeatable, Informative, Scheduled and Portable.

Chapter 2 gets you Repeatable by using ANT to bring together all the various steps you currently perform on your project into a single, one-click build. Chapter 3 works to turn the one-click build into a no-click build using tools as simple as cron as well as more complicated tools like the ANT scheduling tool CruiseControl. By the end of these two chapters your software can be compiling and testing itself automatically each time changes are checked into the version control system. But this is only the beginning.

Chapters 4 and 5 address the "Complete" and "Portable" portions of the CRISP model discussing how to include packaging, release management and deployment into your scheduled build. The last chapter addresses "Informative." How to monitor the build for success or failure, how to notify members of the project team using email, SMS, RSS or even the red and green Lava Lamps I mentioned above.

Summary This book, and the others in the series, provide a much needed set of manuals for getting a good set of basic practices up and running at the start of a project. Unlike the Unit Testing book, there's not a lot of programming in this one, but it's a worthwhile read for any programmer, regardless of experience level.

Many people are becoming interested in eXtreme Programming and Agile methods for software development. These books help to support some of the key ideas of those methods - extensive unit testing and continuous integration.

The main flaw in the book doesn't affect its usefulness, only its readability. Of all the files used in the sample project, the only one covered in any detail is the build file. The source and manifest files that we're writing the ANT file to build are never discussed or described - we are left to guess at what the sample project might contain (unless we download the code from the website). While this didn't change what I was learning (how to manipulate the project files with ANT), I like to understand all the details and this omission did occasionally leave me a little irritated.

You can purchase Pragmatic Project Automation from bn.com. Slashdot welcomes readers' book reviews. To see your own review here, carefully read the book review guidelines, then visit the submission page. If you are interested in the Pragmatic Programmers, see also this interview linked earlier from Slashdot.