Category Archives: Uncategorized

Move Deliberately and Don’t Break Anything

Move Fast and Break Things was first coined at Facebook, and has since become a startup mantra. The idea is that if you’re not occasionally breaking things, you’re not moving fast enough. And of course as a business if you’re not moving fast enough you’ll die.

I recently watch a talk by Brian Goetz (Java Language Architect at Oracle) called “Move Deliberately and Don’t Break Anything.” This post is a recap of that talk and what I thought were important points.

As with most things, Move Fast and Break Things does not apply to everything. Success comes at a price and that price is you have to stop breaking things. At a certain scale (millions of users? billions?) the cost of breaking something is higher than the cost of not moving at a particular speed. Facebook, the originator of the idea, has realized this too and had to modify their philosophy accordingly.

So what does this mean for the Java language?

In Java, there is a tension between Progress and Preservation. Pushing for progress are developers who tend to overestimate the value of code and underestimate the value of working software. Pushing for preservation are the decision makers of the business who need software to not break, period. Some people would like to change the Java language more quickly, but changes can play out in unpredictable ways. A feature is not just a feature, it’s the interaction with every future feature… forever! You are really locked into your decisions if you need to preserve, which you have to do if you are successful and have a billion users.

So the designers and maintainers of the Java language have to move carefully and deliberately. According to Brian Goetz, if you don’t yet know what is the right thing to do, don’t do anything. Just don’t do the wrong thing. This gives you a chance to still do the right thing in the future! I think he makes a good argument for why you can’t have that language feature you really want. 🙂

What do you think? Is the Java language moving too slowly to compete in the modern software engineering world, or moving at the just the right speed to ensure our critical systems stay up and running?

 

Leave a comment

Filed under Uncategorized

Lagom Is Coming For Your Monolith

The Philly JUG had another successful meetup, this time about Lightbend’s new open source project Lagom. It was a timely presentation, as Lagom 1.0 had just been released the day before (on July 26, 2016).

The Lagom website has much better descriptions of what it’s all about, but I’ll give you my first impressions.

Lagom is a microservices framework which is designed from the ground up to be reactive, resilient, and elastic. Event Sourcing and CQRS are implemented as first class citizens, and all calls are asynchronous with first class support for streaming of request and response. It’s easy to see that Lagom is positioned as a high-throughput framework.

Besides the design for high performance, the big advantages I saw were that service registration and location are built in. The framework is designed to work with sets of services at once, which is a plus when dealing with a large project composed of many services.

The downside is that this framework is very new and there is a lot of work to be done. For instance, it only builds with SBT (not Maven or Gradle), and there is no security model.

One thing that is confusing at first is that it builds with SBT and runs with Akka and Play, implying this is a Scala framework. But the only way to use it is via a Java API, and if you dig in you’ll find there is no Scala API. So where is the Scala API? A Scala enthusiast might say “Where is it indeed?!?”  A quick conversation with the Lagom presenters revealed that – to the chagrin of the Scala base – Lightbend has decided that it wants to be involved in the enterprise space, and the opportunity for adoption there lies with producing a Java API first. So although that’s good news for Java developers, Scala developers will unfortunately have to wait.

Give Lagom a try, and let me know what you think in the comments!

1 Comment

Filed under Uncategorized

Java’s Anonymous Inner Classes: Proceed With Caution

Java’s anonymous inner classes can be useful, but you must take care when using them. In particular: A memory leak will occur if an instance of an inner class survives longer than its containing outer class because the inner class maintains a reference to its outer class.

This is not a merely academic concern, this comes up in Android development when we use inner classes to encapsulate and pass around some code, and instances of an outer class (Activities) can be constantly created and destroyed.

Concrete Example

Sometimes we want a quick Set with some elements, and can accomplish this with a one-liner:

Set<String> strings = new HashSet<String>() {{   add("a"); add("b");  }};

Admittedly there are better ways to accomplish this, but this construct is possible and is used from time to time. What is not obvious is that this is actually an instantiation of an anonymous inner class that maintains a reference to its enclosing class, and so is subject to the potential memory leak situation described above.

In full context, here is some code that may look innocent enough (contrived though it may be)

public class Application {

    public static void main(String[] args) throws IOException {

        List<Set<String>> stringList = new ArrayList<>();
        for(int i=0; i < 100; i++) {
            Generator gen = new Generator();
            stringList.add(gen.createStringsInnerClass());
        }
        
        System.out.print("press Enter to continue:");
        System.in.read();
    }

    public static class Generator {
        
        private byte[] lotsOfHiddenStuff = new byte[5_000_000];
        
        public Set<String> createStringsInnerClass() {
            Set<String> strings = new HashSet<String>() {{
                add("a"); add("b");
            }};
            return strings;
        }

        public Set<String> createStringsNormally() {
            Set<String> strings = new HashSet<String>();
            strings.add("a");
            strings.add("b");
            return strings;
        }
    }
}

Analyze This

If we run the above application and monitor it with jconsole, this is what we see:

inner class after gc

It is using over 500MB of memory! This is because the Sets maintain references to their outer classes (which themselves take up a lot of memory) and it is not obvious that the outer class instances are not being properly disposed of.

After switching to use Generator.createStringsNormally(), jconsole looks like this:

non inner class after gc

It is using just over 5MB, as we would hope!

Conclusion

Remember that a memory leak will occur if an instance of an inner class survives longer than its containing outer class. And maybe avoid the “{{ }}” construct because it kind of masks the anonymous-inner-class-ness of your code.

Leave a comment

Filed under Uncategorized

You Don’t Have To REST

This is the last of my thoughts on REST (for the time being) after spending a few weeks doing some research and giving it some thought. See the previous two posts for more background.

What About Change?

According to Fielding: “You can’t have evolvability if clients have their controls baked into their design at deployment. Controls have to be learned on the fly. That’s what hypermedia enables.”

I didn’t quite get this at first. That’s the whole point of versions: clients DO have their controls baked into their design at deployment time, and I don’t have any power over how users of my service are going to write their software.

Yes, We Can (Change)

So I did some more research, and found another discussion with Fielding. Take a look at the discussion, especially at comment 21 (trimmed here for brevity):

“Of course the client has prior knowledge. Every protocol constitutes prior knowledge that the client must know in order to make use of that knowledge. REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them. I have no problem with systems that are true to their own architectural style.”

As Usual: Do What Works For You

I think the idea here, and it’s starting to make more sense after digesting it, is that

  1. REST may still require a priori knowledge on the side of a client to use
  2. REST is not the end-all of API structures and not appropriate to all applications

It is cool, yes, and people like it. But you don’t have to sweat versioning, or sweat following every REST constraint. You can incorporate ideas you find useful, and mention which REST constraints you follow as a shorthand for communication about the architecture of your API.

Your API should do what works for your product. You should do what works for you.

Leave a comment

Filed under Uncategorized

Top Posts of 2014

It’s the end of the year, and as people are wont to do, it’s time for The Year In Review! And before I say anything else, I want to say a special thanks to my readers who are making this blog successful! I hope that everything I write about is fun and useful for you. Let’s review this blog for the year…

My most-viewed blog post of the year, weighing in at almost 3000 views, was Setting Up HTTPS For Spring Boot. At the time (almost a year ago!) Spring Boot was still relatively early in its development, and the documentation to set up HTTPS was meager at best. But I was eager to figure that configuration out, as were, apparently, many others. Fortunately the good folks working on Spring Boot recognized that need and it is way easier now. So that particular blog post probably won’t be getting a lot of traffic in the future, but it’s good to know it helped people out.

My personal favorite post of the year was Imposter Syndrome. It’s my favorite because I feel it speaks to many people at all levels. Various people told me verbally that they felt it was very helpful to them personally and appreciated it. This speaks to the need that this post really filled, and satisfying needs and helping people is really the goal of all this in the first place.

What was your favorite post of the year? What kind of post do you feel helps you the most, that you would like to see more of next year?

Leave a comment

Filed under Uncategorized

Front End Development with Apache

The Apache web server is the single most popular web server on the planet, serving more than half of all website across all domains. Think about that for a minute. Impressive.

Not only is Apache good for serving the world, it’s also good for serving your html files in your personal development environment. Let’s set up Apache!

Installation

This post only deals with Linux, sorry Mac/Windows folks! Many modern Linux distributions come bundled with Apache, but if it is not already installed already, it is easily installable with

sudo apt-get install apache2

When installed, it is also usually set up to run automatically. We can check to see if it’s running with

ps -ef | grep apache2

If we want to control this and actually start or stop it manually, we can cycle Apache with these commands:

/etc/init.d/apache2 start
/etc/init.d/apache2 stop
/etc/init.d/apache2 restart

Serving Content

OK, Apache is up and running. How can we edit html files and have them served locally by Apache?

On the local file system, files are usually served from /var/www/
HTML files and other static content in this location are immediately accessible on port 80 at http://localhost Apache only serves static content, but can forward requests for dynamic content to an application server or servlet container with a reverse proxy.

The big step here is to link our development folder (where all of our html/css/js files are stored and being edited) to the folder where apache can serve them. We can link apache to a development folder like so

sudo ln -s /home/username/path/to/project   /var/www

That’s it!

At this point, a file like /home/username/path/to/project/index.html will be accessible via local web server as http://localhost/index.html. Apache will immediately pick up any changes and immediately serve them with a page refresh.

Happy Front-End-Developing!

Leave a comment

Filed under Uncategorized

Tips for Startup Weekend

If you are thinking of participating in Startup weekend, here are some tips for participants (particularly developers):

Items to Bring

  • Laptop, power cord, mouse
  • ergonomic keyboard (use backpack)
  • extension cord and power strip
  • paper pad and pens
  • cash
  • big headphones to block noise, you generally don’t get your own room
  • business cards
  • substantial or healthy food if you want it (one year they only served sandwiches and pasta, another year they catered and it was better)

General Notes

  • A big help for preparation would be having a RAD tool and being able to produce a shiny app from front to back very quickly, and having a starter app with users and database ready to modify
  • Big themes are mobile devices, should be able to write mobile app (not site) that’s location aware, has login options, etc. Can always do backend rest/json for mobile too
  • There are many online services and api’s you can use, be able to use a rest template or in some way make calls from your app. Leveraging google api’s or other free services can help you put up something very quickly that does something actually useful.
  • Follow the judging criteria carefully, they are there for a reason – specifically to make you think through what it takes to make your business viable. It is impressive when business people research the market validation, potential revenue, and are able to put it all together it in a nice presentation (say, with prezio or a video).
  • Make sure to network during dinner on friday night. You’ll find people you like or don’t like, and if you’re pitching, people you can connect with will be more likely to join your team.

 

These are just notes that I thought of, your mileage may vary. But if you want to check out startup weekend for the first time, these ideas will smooth your way!

Leave a comment

Filed under Uncategorized