Typesafe Stack 2.0 Released: Q&A with Typesafe President and CEO

Typesafe issued a press release today including this initial paragraph:

Typesafe today announced the release of Typesafe Stack 2.0, the latest version of its open source software stack. Typesafe Stack 2.0 is a comprehensive platform for building applications in Java and Scala that can scale to the largest workloads in cloud computing and virtualized enterprise datacenter environments. The release adds the innovative Play web framework for the first time, and includes Akka event-driven middleware 2.0, with significant enhancements for building concurrent and distributed applications.

This newly released Typesafe Stack 2.0 might provide a nice way to introduce oneself to Scala while addressing modern development needs. I've long felt the best way to learn a new language, framework, or library is to use it in a practical situation. Jan Machacek made a similar point in the JavaWorld article Learn Scala with Specs2 Spring, where he discussed learning Scala as one used it with his company's Specs2 Spring Extension.

Because I'm new to Play, Akka, and even Scala, I welcomed the opportunity to ask the folks at Typesafe questions about the Typesafe Stack 2.0 from a beginner's perspective. The following questions were asked of and answered by Typesafe President and CEO Donald Fischer. With these questions, I tried to find out what I needed to know to determine the motivation for beginning use of Typesafe Stack 2.0 and where to start in my efforts to learn and use it.

Q&A with Typesafe CEO Donald Fischer

Question: What are the most compelling advantages of the Typesafe Stack 2.0?

Some of the most compelling advantages of the Typesafe Stack versus legacy platforms are:

• Strategies for working in a world of horizontal scale. Modern software needs to take advantage of more cores and more machines, rather than faster single cores.
• An emphasis on developer agility, productivity, and enthusiasm. Developers want to work quickly and focus on business logic rather than boilerplate.
• Fewer bugs. The Typesafe Stack has tools to avoid bugs up front. For example, Akka helps you avoid tricky thread synchronization issues, and Scala helps you write side-effect-free, typesafe code with fewer opportunities for error.
• An emphasis on pragmatic interoperability. The Typesafe Stack APIs can be used from Java or Scala or both; and they can be adopted incrementally. It's as simple as adding some jars to your project.

Question: How much familiarity with Scala is required to use Typesafe Stack 2.0?

While the Typesafe Stack includes Scala, and is built on a Scala foundation, both the Play web framework and Akka middleware offer native APIs for both Java and Scala. So developers can build applications that leverage all of the capabilities of the Typesafe Stack without any specific knowledge of Scala (though we don't think they'll be able to resist the added productivity that Scala provides once they get a taste).

Question: On a spectrum of 100% Java to 100% Scala with a combination of the two between those ends of the spectrum, what portion of the spectrum is supported by Typesafe Stack 2.0? (Can one use Typesafe Stack 2.0 with Java only?)

100% of the functionality in the Typesafe Stack frameworks (Akka and Play) is supported for both Scala and Java.

Question: What is the easiest way to get started using the overall Typesafe Stack 2.0?

We've put together a Getting Started Guide, here: http://typesafe.com/resources/getting-started/

Question: What online resources are available regarding the use of Typesafe Stack 2.0?

We've collected a variety of resources including videos from project contributors, commercial users, and the community here: http://typesafe.com/resources

Question: Are there any books available or planned that cover the individual products within Typesafe Stack 2.0 as well as the overall integrated stack?

Yes, we've accumulated a collection of books here: http://typesafe.com/resources/books We're proud that several of these books are authored by Typesafe employees, including Martin Odersky, Josh Suereth, Heiko Seeberger, and Philipp Haller.

Question: What is the licensing for Typesafe Stack 2.0 and is it consistent across the individual products and the overall stack?

The Typesafe Stack is 100% open source. It's complemented by the commercial Typesafe Subscription, which adds support, maintenance, and tools including the new Typesafe Console. The Typesafe Console is available exclusively to Typesafe Subscription customers.

Question: What potential enhancements are planned for Typesafe Stack 2.0?

Upcoming releases of the Typesafe Stack will include additional clustering features and enhanced support for building applications that adapt to elastic cloud environments.

Screen Images

I was provided with some images that I have posted next. Note that these display the Typesafe Console, which is only available via the Typesafe Subscription option.

My Own Thoughts and Observations

Typesafe Stack 2.0 appears to offer developers several advantages, one of which is the ability to learn the Scala language, the Play framework, and the Akka toolkit all while solving difficult problems associated with modern software development. The press release alludes to these problems in the sentence, "Typesafe provides the most scalable software platform designed for the computing architectures of the future -- multicore, parallel and cloud applications."

Typesafe's licensing model is a familiar one with significant product (the Typesafe Stack 2.0) available via an open source license and add-on tools available for a commercial subscription. The advantage of this is that a developer can "play" (no pun intended) with Typesafe Stack 2.0 and then later move to Typesafe Subscription as needed and desired. It has been my experience that, generally speaking, it is an advantage to have a large corporate sponsor of an open source product I am using. Corporate sponsorship tends to mean dedicated resources invested in improving and maintaining the product. Examples include the Spring Framework and Groovy (SpringSource), NetBeans and GlassFish (Sun/Oracle), Eclipse (IBM), etc. Typesafe's optional commercial support for Typesafe Stack 2.0 is potentially useful for customers, but Typesafe's apparent commitment to the product's development and maintenance is highly valuable as well.

Specific licensing information for the products of Typesafe Stack 2.0 can be found at the Typesafe Licenses page. As of this writing, this page reports that "Scala and the Scala IDE for Eclipse are available under the Scala License", Play and Akka are licensed with the Apache License, Version 2.0, and "Simple Build Tool (sbt) is available under the BSD license."

Conclusion

The press release, the answers to my questions above, and the plethora of resources available on the Typesafe site all imply a highly beneficial product. I am not in any way affiliated with Typesafe and I have not yet tried Typesafe Stack 2.0 out for myself, but it looks very promising. If nothing else, playing with it and possibly applying it to real problems might be one of the best ways to learn Scala, Play, and Akka, but one can always fall back to Java when using it if necessary.

JavaOne 2012 Call for Papers

The JavaOne 2012 Call for Papers has been issued. The window for submission is March 14 through April 9. Notifications regarding accepted and declined proposals will be made in late May or early June and speakers whose proposals are accepted are expected to confirm their session by the middle of June. JavaOne 2012 is September 30 through October 4, 2012, in San Francisco, California. JavaOne 2012 is again being held in conjunction with Oracle OpenWorld 2012 and OpenWorld begins its call for papers on March 14 as well.

How Badly Do We Want a New Java Date/Time API?

The current Java.net poll question is, "How critical is it for JSR-310 (new Date and Time API) to be implemented in Java 8?" At the time of my writing of this post, nearly 150 respondents have voted and an overwhelming percentage have answered either "Very" (53%) or "It would be nice, but we can get by using the current classes" (22%). With 3/4 of the respondents feeling that it would either "be nice" or is "very important" to get a new Java Date/Time API, I think it's safe to say that Java's current Date and Calendar approach has not grown on us. Perhaps my biggest surprise so far with the survey results is that 2% of the respondents have stated, "I prefer the current date and time classes." Maybe that's from the people who wrote those classes?

I tend to use Java's date/time/calendar APIs off and on. When I use them, I really don't like them, but do start to tolerate them. I begin to forget how much I loathe them until I use them again. I recently helped a colleague familiar with Java (but not with the date/time APIs) to understand how to do some Date/Calendar/String manipulation and presentation. Explaining this mess out loud to him made the ridiculous difficulty of using these too-flexible APIs even more obvious to me. I could see on his face that he was thinking I was either kidding him or didn't know what I was talking about. Although I've gotten to the point where I can make them make do, it's much more difficult than it should be.

Much has been written about the woes of date/time handling in Java. Rob Sanheim wrote in 2006 about date/time-related problems in three of his Top Five Worst APIs in Java (Calendar, Date, and DateFormat/SimpleDateFormat). Java's Date-handling is focused on in Cameron Purdy's 2005 post The Seven Habits of Highly Dysfunctional Design. Tero Kadenius reminded us in the 2011 post Handling dates in Java that "The date/time API in Java is notoriously painful to work with." The aptly named post Java Dates Still Suck was published in 2009.

The current Java.net survey confirms my feeling after working with numerous Java developers and after reading many blogs and articles that the vast majority of Java developers are anxious to get a better standardized way of handling dates and times in Java.

NetBeans 7.1's Internal Compiler and JDK 6 Respecting Return Type for Method Overloading

I was first exposed to Java after several years of C++ experience and so it seemed natural when I learned that Java does not allow method overloading based on return type. The Defining Methods section of the Classes and Objects lesson in the Java Language Tutorial states, "The compiler does not consider return type when differentiating methods, so you cannot declare two methods with the same signature even if they have a different return type." Indeed, as Vinit Joglekar has pointed out, "It is an accepted fact that Java does not support return-type-based method overloading." The StackOverflow thread Java - why no return type based method overloading? explains why this is the case in Java. Given this, I was surprised when a colleague showed me a code snippet with two overloaded methods with the same runtime signature that compiled in JDK 6 as long as the return types differed.

The following class compiles successfully with JDK 6, but not with JDK 7.

Compiles in JDK 6 But Not in JDK 7

package examples.dustin;

import java.util.Collection;

/**
 * Simple example that breaks in Java SE 7, but not in Java SE 6.
 * 
 * @author Dustin
 */
public class Main
{
   public static String[] collectionToArray(final Collection<String> strings)
   {
      return new String[] { "five" };
   }

   public static int[] collectionToArray(final Collection<Integer> integers)
   {
      return new int[] { 5 };
   }
   
   /**
    * Main function.
    * 
    * @param arguments The command line arguments; none expected.
    */
   public static void main(String[] arguments)
   {
   }
}

As described in Angelika Langer's What Is Method Overloading?, the above code should not compile. It doesn't in Java SE 7. In NetBeans 7.1, it doesn't. Or, more properly, it's a mixed bag.

As the screen snapshot below demonstrates, NetBeans 7.1 builds the source code above fine as shown in the Output Window when the version of Java associated with the project is Java SE 6. However, the NetBeans editor shows the red squiggly lines indicating compiler error. The next image shows what the error message is.

Although NetBeans 7.1 is able to build the code shown above when it's part of a project associated with Java SE 6 (Update 31 in this case), the code editor still reports the error shown above. This is because NetBeans uses a different version of the Java compiler internally than the one explicitly associated with the project being edited. If I change the version of Java associated with the NetBeans project for the source code above, it will no longer build in NetBeans. This is shown next.

There are a couple interesting things about this bug. First, the fact that this code compiles fine in Java SE 6 but is addressed and does not compile in Java SE 7 means that it is possible for code working in Java SE 6 to not work when the code base is moved to Java SE 7. I downloaded the latest version of JDK 6 available (Java SE 6 Update 31) and confirmed the original code shown above still builds in Java SE 6. It does not build in Java SE 7.

There are other versions of the code above that do not build in Java SE 6 or in Java SE 7. For example, if the code above is changed so that the methods return the same type, the code doesn't build even in Java SE 6. Similarly, if the Collection parameters to the two overloaded methods include a "raw" Collection (no parameterized type), it won't compile in Java SE 6 either. Of course, even if the return types are different, if the same Collection parameterized types are passed to both overloaded methods, even Java SE 6 won't compile this. These three situation are depicted in the following three screen snapshots.

The code that builds in Java SE 6 but not in Java SE 7 needs to have overloaded methods that differ in both return types and in terms of the parameterized types of the collections that make up their method parameters. It doesn't matter if a given return type matches or is related to the parameterized type of the method's parameter as long as they differ. If the return types are the same, Java SE 6 detects a compiler error. Java SE 6 also detects the error if the erased parameters boil down to the same collection after erasure and the return types are not different.

A second interesting thing about this bug is how its handled in NetBeans. Because NetBeans use its own internal compiler that does not necessarily match the version of the compiler that the developer has associated the IDE project to, you can run into situations like this where the code actually builds in the IDE, but the IDE's functionality such as code editors and project browsers indicate the code breaking.

Because NetBeans 7.1 uses its own internal Java compiler for the code editor, one might wonder if this means Java 7 features could be sneaked in and would work in the IDE but then would not build when attempted from the command line or when explicitly built in the IDE. The next screen snapshot demonstrates why that is not the case. In that snapshot, a Java 7 specific feature is in the code and NetBeans 7.1 properly warns that this is not compatible with the Java 1.6 source setting.

Bug 6182950 (methods clash algorithm should not depend on return type) has addressed the issue in JDK 7, but not in JDK 6. A related bug is Bug 6730568 ("Type erasure affects return types + type parameters"). Three additional references that provide sufficiently more background details are two StackOverflow threads (Differing behaviour between Java 5 & 6 when overloading generic methods and What is the concept of erasure in generics in java?) and the Java Tutorial entry on Type Erasure.

The colleague who showed me this issue realized its existence because NetBeans 7.1 reported the "name clash ... have the same erasure" even when he was working with Java SE 6 code. This discovery was "accidental" due to the newer version of NetBeans using Java SE 7 compiler internally, but he welcomed the opportunity to fix the issue now rather than when he migrates to Java SE 7.

I found this issue worth posting a blog post on because it provides a warning about a bug that may already be in some Java SE 6 code bases but will be made all too evident when the code base is moved to Java SE 7. I also posted this because I think it's important to be aware that modern versions of NetBeans use an internal compiler that may be of a different version than the compiler the developer has explicitly associated with his or her NetBeans project.

Useful Lesser Known Java Classes

A recent reddit Java thread is titled "Share a useful class from the standard Java Class Library!" and starts with the comment, "There are so many available classes and sometimes ones exist that you don't realize. Share one that you use that the rest of us may not be aware of!" In this post, I look at some of the (mostly JDK) classes mentioned in the forty (at time of this writing) responses to this request.

Several respondents provided concurrency-related Java classes such as Executors, java.util.concurrent.CountDownLatch, java.util.concurrent.atomic.AtomicInteger, ThreadLocal, and "anything in the packages" java.util.concurrent and java.util.concurrent.atomic.

Several classes related to String manipulation are mentioned in this thread. These include StringBuffer, and StringBuilder. I have blogged about these String-related classes in the post String, StringBuffer, and StringBuilder: There Is A Performance Difference. Other String-related classes mentioned in this thread include java.util.StringTokenizer and Apache Commons' StringUtils (which is mentioned in my post Checking for Null or Empty or White Space Only String in Java). The java.util.Scanner class also receives mention for making text parsing easier.

In the area of user interface work, java.awt.geom package is mentioned as are java.awt.Desktop and javax.swing.SwingUtilities. The class java.awt.Point is highlighted with an explanation that concludes, "But any two int pairs work and easier to pass to/from a function (instead of an array or whatever)." I could have used it instead of my own nested Coordinate class or instead of the JavaFX javafx.util.Pair class when crafting a JavaFX Christmas tree. The class java.awt.Robot is also mentioned in the thread and I have discussed that class in the post Screen Snapshots with Java's Robot.

Not surprisingly, several Java collections make the list. These include java.util.EnumSet and EnumMap (see my post The Sleek EnumMap and EnumSet), java.util.ArrayDeque (see my post The Java SE 6 Deque), java.util.PriorityQueue, java.util.Arrays, and java.util.Collections (see my post The Java Collections Class).

In my opinion, java.lang.ClassLoader, java.util.ServiceLoader, and java.nio.file.FileVisitor are some of the more elaborate and specialized classes mentioned in the reddit Java thread. Many of us use strong references by default, but java.lang.ref.WeakReference and java.lang.ref.SoftReference receive mention in this thread as well.

Finally, a class and a method that are referenced that I often use are the BigDecimal class (one of my many posts alluding to this class is Caution: Double to BigDecimal in Java) and the method System.nanoTime().

Conclusion

The reddit/Java thread Share a useful class from the standard Java Class Library! represents ideas from the Java community regarding lesser known useful Java classes generally available in the JDK. I liked many on the list and can think of additional examples as well (and likely more will appear from other posters). In particular, I think JDK 7's Objects class is mighty useful and less known than it should be. I also agreed with one of the responses which stated, "Add the google guava library for tons of useful classes" and have written several posts on Guava.

Viewing JavaFX 2 Standard Colors

The JavaFX 2 class javafx.scene.paint.Color includes several fields that are static Color members. I have taken advantage of the convenience of these publicly available static fields in many of my JavaFX 2 examples shown in this blog. There is a lengthy list of these predefined Color fields ranging (in alphabetical order) from Color.ALICEBLUE to Color.YELLOWGREEN. I have sometimes thought it would be nice to quickly see what some of the less obvious colors look like and the simple JavaFX 2 application featured in this post provides a sampling of those colors.

The sample JavaFX 2 application shown here uses simple Java reflection to introspect the JavaFX Color class for its public fields that themselves of type Color. The application then iterates over those public fields, providing information about each color such as the color's field name, a sample of the color, and the red/green/blue components of that color.

The final row allows the user to specify red/green/blue values to see how such a color is rendered. This is useful if the user sees a standard color that is close to what he or she wants and the user wants to try adjusting it slightly. To ensure meaningful values for displaying a color based on provided red/green/blue values, the application ensures that entered values are treated as doubles between 0.0 and 1.0 even if they are not numbers or are numbers outside of that range.

The simple JavaFX 2 application showing standard Color fields is shown in the next code listing.

JavaFxColorDemo.java

package dustin.examples;

import static java.lang.System.err;
import java.lang.reflect.Field;
import javafx.application.Application;
import javafx.event.EventHandler;
import javafx.scene.Group;
import javafx.scene.Scene;
import javafx.scene.control.*;
import javafx.scene.input.MouseEvent;
import javafx.scene.layout.HBox;
import javafx.scene.layout.Pane;
import javafx.scene.layout.VBox;
import javafx.scene.paint.Color;
import javafx.scene.shape.Rectangle;
import javafx.scene.shape.RectangleBuilder;
import javafx.stage.Stage;

/**
 * Simple JavaFX 2 application that prints out values of standardly available
 * Color fields.
 * 
 * @author Dustin
 */
public class JavaFxColorDemo extends Application
{
   /** Width of label for colorn name. */
   private final static int COLOR_NAME_WIDTH = 150;
   /** Width of rectangle that displays color. */
   private final static int COLOR_RECT_WIDTH = 50;
   /** Height of rectangle that displays color. */
   private final static int COLOR_RECT_HEIGHT = 25;

   private final TextField redField = TextFieldBuilder.create()
      .text("Red Value").build();
   private final TextField greenField = TextFieldBuilder.create()
      .text("Green Value").build();
   private final TextField blueField = TextFieldBuilder.create()
      .text("Blue Value").build();
   private final Rectangle customColorRectangle = RectangleBuilder.create()
      .width(COLOR_RECT_WIDTH).height(COLOR_RECT_HEIGHT)
      .fill(Color.WHITE).stroke(Color.BLACK).build();

   /**
    * Build a pane containing details about the instance of Color provided.
    * 
    * @param color Instance of Color about which generated Pane should describe.
    * @return Pane representing information on provided Color instance.
    */
   private Pane buildColorBox(final Color color, final String colorName)
   {
      final HBox colorBox = new HBox();
      final Label colorNameLabel = new Label(colorName);
      colorNameLabel.setMinWidth(COLOR_NAME_WIDTH);
      colorBox.getChildren().add(colorNameLabel);
      final Rectangle colorRectangle = new Rectangle(COLOR_RECT_WIDTH, COLOR_RECT_HEIGHT);
      colorRectangle.setFill(color);
      colorRectangle.setStroke(Color.BLACK);
      colorBox.getChildren().add(colorRectangle);
      final String rgbString =
           String.valueOf(color.getRed())
         + " / " + String.valueOf(color.getGreen())
         + " / " + String.valueOf(color.getBlue())
         + " // " + String.valueOf(color.getOpacity());
      final Label rgbLabel = new Label(rgbString);
      rgbLabel.setTooltip(new Tooltip("Red / Green / Blue // Opacity"));
      colorBox.getChildren().add(rgbLabel);
      return colorBox;
   }

   /**
    * Extracts a double between 0.0 and 1.0 inclusive from the provided String.
    * 
    * @param colorString String from which a double is extracted.
    * @return Double between 0.0 and 1.0 inclusive based on provided String;
    *    will be 0.0 if provided String cannot be parsed.
    */
   private double extractValidColor(final String colorString)
   {
      double colorValue = 0.0;
      try
      {
         colorValue = Double.valueOf(colorString);
      }
      catch (Exception exception)
      {
         colorValue = 0.0;
         err.println("Treating '" + colorString + "' as " + colorValue);
      }
      finally
      {
         if (colorValue < 0)
         {
            colorValue = 0.0;
            err.println("Treating '" + colorString + "' as " + colorValue);
         }
         else if (colorValue > 1)
         {
            colorValue = 1.0;
            err.println("Treating '" + colorString + "' as " + colorValue);
         }
      }
      return colorValue;
   }

   /**
    * Build pane with ability to specify own RGB values and see color.
    * 
    * @return Pane with ability to specify colors.
    */
   private Pane buildCustomColorPane()
   {
      final HBox customBox = new HBox();
      final Button button = new Button("Display Color");
      button.setPrefWidth(COLOR_NAME_WIDTH);
      button.setOnMouseClicked(new EventHandler<MouseEvent>()
      {
         @Override
         public void handle(MouseEvent t)
         {
            final Color customColor =
               new Color(extractValidColor(redField.getText()),
                         extractValidColor(greenField.getText()),
                         extractValidColor(blueField.getText()),
                         1.0);
            customColorRectangle.setFill(customColor);
         }
      });
      customBox.getChildren().add(button);
      customBox.getChildren().add(this.customColorRectangle);
      customBox.getChildren().add(this.redField);
      customBox.getChildren().add(this.greenField);
      customBox.getChildren().add(this.blueField);
      return customBox;
   }

   /**
    * Build the main pane indicating JavaFX 2's pre-defined Color instances.
    * 
    * @return Pane containing JavaFX 2's pre-defined Color instances.
    */
   private Pane buildColorsPane()
   {
      final VBox colorsPane = new VBox();
      final Field[] fields = Color.class.getFields(); // only want public
      for (final Field field : fields)
      {
         if (field.getType() == Color.class)
         {
            try
            {
               final Color color = (Color) field.get(null);
               final String colorName = field.getName();
               colorsPane.getChildren().add(buildColorBox(color, colorName));
            }
            catch (IllegalAccessException illegalAccessEx)
            {
               err.println(
                  "Securty Manager does not allow access of field '"
                  + field.getName() + "'.");
            }
         }
      }
      colorsPane.getChildren().add(buildCustomColorPane());
      return colorsPane;
   }

   /**
    * Start method overridden from parent Application class.
    * 
    * @param stage Primary stage.
    * @throws Exception JavaFX application exception.
    */
   @Override
   public void start(final Stage stage) throws Exception
   {
      final Group rootGroup = new Group();
      final Scene scene = new Scene(rootGroup, 700, 725, Color.WHITE);
      final ScrollPane scrollPane = new ScrollPane();
      scrollPane.setPrefWidth(scene.getWidth());
      scrollPane.setPrefHeight(scene.getHeight());
      scrollPane.setContent(buildColorsPane());
      rootGroup.getChildren().add(scrollPane);
      stage.setScene(scene);
      stage.setTitle("JavaFX Standard Colors Demonstration");
      stage.show();
   }

   /**
    * Main function for running JavaFX application.
    * 
    * @param arguments Command-line arguments; none expected.
    */
   public static void main(final String[] arguments)
   {
      Application.launch(arguments);
   }
}

The snapshots shown next demonstrate this simple application. The first snapshot shows the application after loading. The second snapshot shows the application after scrolling down to the bottom and demonstrates use of the Tooltip and of the TextField.setPrompt(String) method. The third image shows the results of providing red/green/blue values and clicking on the button to see the corresponding color.

The simple JavaFX 2 application shown in this post makes it easy to get an idea of what colors are available as standard JavaFX 2 public static Color fields. It also allows one to enter red/green/blue values that might be provided to the Color constructor to obtain an instance of Color.

Late February 2012 Software Development Links of Interest

This post summarizes and provides links to some online resources related to software development that have recently captured my attention. Topics include Linux, DevOps, dynamic typing versus static typing, abstraction versus simplicity, and cloud computing.

Linux

Several posts on Linux have recently captured my interest. The post 10 free Linux e-books provides a list of ten freely available Linux books. Each book is featured with an image of its cover along with a brief description and a link to the electronic version of the book. Titles include Advanced Linux Programming (2001), Java Application Development on Linux (2005), and Linux Network Administrator's Guide, 2nd Edition (2000). One of the free referenced electronic Linux titles is The Linux Command Line: A Complete Introduction, a book that receives rave reviews from Peter N. M. Hansteen in yesterday's post The Linux Command Line Is A Very Appealing Story. The Linux Command Line has tremendous breadth, covering topics ranging from use of vi, to shell scripting to basic Linux commands. Speaking of Linux commands, the post Linux Command Line Tips that Every Linux User Should Know provides an interesting summary of Linux command-line commands.

DevOps

I remain uncommitted to the long-term value of the DevOps movement, but have certainly not made up my mind for good yet and am waiting it out to see if more substance comes from it. For example, even though I've tangentially touched on DevOps before, I still have not made a "Label" for it to mark my blog posts that cover the topic. Edward Capriolo's post DevOps has no chance is not on the fence about the subject. The post concludes with a point that I think's worth considering: "It is a left brain right brain thing. The qualities that make a good dev usually make a terrible ops person and vice versa. The world is ok that way."

Dynamic Typing

As software developers, we cannot seem to help ourselves and must continue the debate about whether static or dynamic typing is best. I've found advantages to both (that most realistic and fair developers will acknowledge), so it truly is a case of what best fits the particular task at hand as well as the task's surrounding development environment. As a general rule of thumb, I prefer dynamic typing for small efforts, especially scripting, but begin favoring static typing as a program gets larger and more people are involved. It sounds bad, but in essence I prefer static typing when I cannot trust "the other person" (which may be myself on a large enough code base). In Why I don’t like Dynamic Typing, John Mount states, "I find the pain of having to type or read through extra declarations is small (especially if you know how to copy-paste or use a modern IDE). And certainly much smaller than the pain of the dynamic language driven anti-patterns of: lurking bugs, harder debugging and more difficult maintenance. ... Initial coding is not the only phase of the software lifecycle." Mount appropriately recognizes that "there is, of course, no prior reason anybody should immediately care if I do or do not like dynamic typing," but offers some valid arguments for static typing (just as Martin Fowler has offered for dynamic typing). The reddit/programming comments/responses are a reminder that if you want a blog post to get attention, write about static typing versus dynamic typing.

Too Much Abstraction

Several experienced colleagues and I have been discussion off and on over recent months the seeming over-abstraction we've seen in certain frameworks and in code bases we've been exposed to. In the post Peak Abstraction, Tom Hammersley hits on this topic. Hammersley has done a nice job of articulating how this is especially likely to happen with a developer who is no longer new, but has not yet learned some hard lessons from more experience: "There is a common pattern. It typically occurs after 3-4 years of professional practice. A programmer is growing in his confidence. He begins to tackle more complex, challenging problems. And, he reflects those problems with complex, challenging data structures. He has not yet learnt the fine art of simplicity." Simplicity is often recognized as a desirable virtue in software development, but it is all too easy to become enamored with excessive abstraction, especially when one sees abstraction replied layer upon layer frequently in so many other aspects of software.

Anticipating Cloud Failures

In my summary of 2012 software development developments, I talked about the continuing prevalence of cloud computing in software development literature and also highlighted cloud failures in 2011 in the "honorable mention" list. The post New Year, New Security Breach; Three Potential Cloud Provider ‘Screw Ups’ to Watch cites 3 big screw-ups you can expect from cloud providers in 2012, which lists three expected cloud provider blunders in 2012: security, migration cost, and performance. The "New Year, New Security Breach" post also provides an interesting "Security Breach Timeline" for 2011.

Conclusion

There is a lot going on in the world of software development and the posts referenced above provide a very small taste of what's going on out there in the blogosphere.