Earlier this week I attended FOWD, a fantastic conference for web designers and developers in the heart of London. One of the highlights of the trip was the JavaScript Web Warrior workshop with Addy Osmani. He mentioned that using Chrome Experiments you could edit your JavaScript right there in Chrome, without needing to bother with any other editors. Here’s how to enable that feature:
Download Chrome Canary. Standard Chrome doesn’t have this feature yet, so it’s time to live on the edge. Of course, Canary can be installed alongside Chrome without any issues, so it’s cool.
From Canary, navigate to chrome://flags and enable the Developer Tool Experiments
Restart Canary and then navigate to the site, hosted locally, that you want to work with.
Open up Chrome Dev Tools, and click on the settings cog. From here, navigate to the Workspace section.
This is where you can set up the mappings from URL to file system.
Obviously you will need to give Chrome access to your filesystem.
And that’s it – you’re good to go.
In the following video, Addy gives a run down on how to use this workspaces feature:
Something every developer and team aspires to is shipping great software. But as we all know, it doesn’t always work out that way. So what can we learn from Chris Vander Mey’s Shipping Greatness ?
First, let’s take a look at the authors credentials; Chris has worked as a product manager at Google and an engineering manager at Amazon; two companies who have a pretty good track record when it comes to delivering products. So, I guess he has learned a thing or two.
The book is split into two parts. The first focusses on the step by step shipping process that the author has seen used in Google and Amazon. This starts with defining your misson, puts a spotlight on creating a great user experience and deals with the testing and measurement of your delivery.
The second part of the book looks at the best practices and techniques that you should use as someone trying to orchestrate a great delivery. Skills that you will read about in this section include how to build a team that is up to the task, and how to be a great communicator and decision maker.
While the book will appeal to anyone who wants to build great, meaningful software products, it is probably managers and technical leads that will get the most out of Shipping Greatness.
There’s a really nice “10 Principles of Shipping” list at the back of the book, which any leader should keep in mind – maybe put a printout up on the team whiteboard. These principles include tips such as ”start with the user and work outward” or “you’ll never do the whole job, so first od that which only you can do”. As well as showing the way to deliver greatness, this book could help improve how you lead your team.
If you want to execute lean practices at your startup, then Running Lean by Ash Maurya should be top of your reading list. Highly regarded by reviewers across the board, the book claims to help you to Iterate from Plan A to a Plan That Works. So how does it do that?
The book is broken into four distinct parts. First, you are introduced to a roadmap of how to apply the process, which is made up of three meta-principles: document your plan A, identify the riskiest parts of your plan, and then, systematically test your plan. For software developers familiar with agile processes, this may sound familiar. But don’t let that stop you from learning how to apply these principles.
I claim to understand lean/agile and any other buzzword that claims to get the right product out quickly. But understanding and execution are two entirely different things. Ash does a fantastic job of explaining the intricacies of each of these steps. Even the documenting of your plan A gives some great tips on working out what your business model should be, what to prioritise and how to track progress.
The part that gets most focus in the book is the testing of your plan, where you need to go through the steps of understanding the problem, defining the solution and validating the solution.
As a software developer, this book made me realise the value in a defined iterative process. As someone who’d like to create my own company, this book provides a useful handbook for the early days of a startup.
Until recently, Ant has been my build system of choice: functional, proven and, it just works. So, I was intrigued to see what Gradle could provide instead. So when Hubert Klein Ikkink , one of DZone’s leading MVBs on Groovy, gave me the chance to review his Gradle Effective Implementation Guide , I could hardly refuse.
The book begins with a really good introduction into what Gradle actually is. Useful for Gradle newbies like me, but most people can probably afford to skip it. The book then goes through the main things you’ll want to do in your Gradle build scripts; using tasks and dealing with files and directories; before showing how easy it is to use Gradle for your Java projects. Later on the book illustrates how you can use the Scala or Groovy plugins to build projects for those languages, and how to build multiple projects that are dependent on each other.
I found the chapter on writing custom tasks and plugins to be particularly useful. Most importantly, the author explains how you can write tests for your custom plugins to ensure they work as expected. As you’d expect, Gradle has good IDE and continuous integration support, all of which is explained in the last chapters.
The book will probably appeal more to people who are new to Gradle. I found the explanations to be be really detailed and useful. Whether I’ll use Gradle for my next project, I’m not sure – but it certainly is tempting
Throughout 2012, JavaScript seems to be solving problems across the industry, causing some justifiable hype across a number of libraries and frameworks. Oracle’s Project Nashorn was recently announced, due for release with Java 8 in late 2013, which will allow JavaScript to be embedded in Java applications and to develop standalone JavaScript applications.
It makes sense that the JVM maintains it’s relevance by providing an improved JavaScript engine: there have been indications that performance is up to five times faster than the current Rhino implementation and the engine footprint is five times smaller.
We spoke to Henrik Stahl, senior director of Java product management at Oracle to find out more.
DZone: Where did the motivation for Nashorn come from?
Henrik Stahl: Oracle recognizes that multi-language support is important to Java
The Rhino engine currently used is dated and not architected together with the JVM
Writing a new engine allows us to validate the Invokedynamic (JSR-292) feature in JDK 7, leverage all new language and JVM features in JDK 8, as well as provide a seamless way of using Javascript and Java code in the same program.
DZone: How long have Oracle been working on it internally?
Henrik: We have been working on Nashorn for the past year and a half.
DZone: Was it originally for any other purpose or products?
Henrik: No. The goals have remained the same since the project’s inception, although we have found ways to use it that we hadn’t originally anticipated; such as using it as a backend for the Javascript development and debugging features in Netbeans.
DZone: How much of Nashorn is already complete?
Henrik: The Nashorn engine is passing all ECMAScript 5.1 compliance tests. Early access users have been able to switch their application from Rhino to Nashorn without major issues.
DZone: And what still needs to be added?
Henrik: The team is currently focused on robustness and performance as well continuing to evaluate potential JVM optimizations. The team is also starting to explore support for upcoming ECMAScript 6.0 features.
DZone: Why do you think that Nashorn will be more successful than Rhino, the previous JS implementation on the JVM?
Nashorn significantly outperforms Rhino, and the gap will increase even more as we now move focus from spec compliance and stability to performance
Nashorn implements a new meta-object protocol that simplifies calling Java APIs from JavaScript, and enables seamless interactions between JavaScript and Java.
Nashorn enables infrastructure providers to consolidate their JavaScript and Java workloads on single virtual machine technology, and leverage the JVM management, debugging and profiling capabilities.
Everyone wants to be the next big thing, but few of us are fortunate enough to know where to start. Luckily, Paul Graham gave some insight into this in his latest post, How To Get Startup Ideas.
There’s one piece of advice that keeps coming up, whether it’s in this latest post from Paul, or the Steve Jobs biography - build something that you would want to have. At least this way you have a customer from day 1, right?
Another benefit of “you being the customer” is that you know exactly what the problem is – no need to spend time testing markets early on. Sometimes testing the market means asking friends and family whether they would find a particular idea useful. That’s ok, but bear in mind that it takes a strong friend to tell you that your idea sucks.
These days there is more and more pressure on people in software to come up with great ideas. But this pressure just ends up in below-par products, or worse, products that no one wants:
Why do so many founders build things no one wants? Because they begin by trying to think of startup ideas. That m.o. is doubly dangerous: it doesn’t merely yield few good ideas; it yields bad ideas that sound plausible enough to fool you into working on them.
Paul mentions one more point that resonates with me – thinking that the idea is too late, that someone has already done it, and that I should just force myself to think up something different, leaving a perfectly good idea behind
Because a good idea should seem obvious, when you have one you’ll tend to feel that you’re late. Don’t let that deter you. Worrying that you’re late is one of the signs of a good idea. Ten minutes of searching the web will usually settle the question. Even if you find someone else working on the same thing, you’re probably not too late.
How many times has this been proven over the last three decades? IBM has the PC industry sewn up and along came Apple. Altavista was a great search engine (in it’s time) and now we all use Google. The MP3 player market was flooded, and the iPod became the default.
It’s never too late to disrupt, you just need to believe in your idea.
Already considered as quite an impressive tool, Chronon 3 was released recently, bringing even more features and improvements. Top of the list are the performance improvements; and the improvements delivered cannot be understated. You won’t need to worry about running out of memory with Chronon anymore.
I asked Prashant Deva, Chronon’s founder, about how exactly they got the improvements. Because of the amount of feedback the team were getting about OutOfMemory errors, Chronon 3 was completely re-architected from the ground up. Obviously, this process took a lot of time, and is the reason there was a long time between the previous release and Chronon 3.
Prashant gave me an amazing insight into how Chronon recorder works in the background:
If you were to look at the source code of a computer program, especially a single threaded program, you will notice that you can pretty much predict what a program is going to do. Sure the program will have branches and loops but those brances will be dependent on the values of some object in memory and if you know its value, then you can predict the flow.
Chronon 3 Recorder is based entirely on this idea of ‘predictions’. The Recorder reads the bytecode of your application and does a static analysis of your code.
From this analysis, it creates a bunch of ‘predictions’, about how your program will execute.
An example of a prediction might be :
Call bar() at line 46 in Foo.java.
Then it monitors the execution of your program.
It keeps adjusting the ‘prediction’ data structures to account for what your program acutally does.
Then the recording data that is generated is really just how much your program differs from these predictions.
For example, in the case of the earlier prediction:
Lets say you have 2 threads:
Thread 1 :
Execution matches prediction completely
Calls Foo.bar() at line 46 in Foo.java.
In this case, no recording data is generated, since the prediction is matched 100%.
Thread 2
Calls overloaded method Foo2.bar() at line 46 in Foo.java.
In this case, the prediction data here will be modified, for this thread only, to account for the fact that 2 methods may be called here – Foo.bar() and Foo2.bar()
Then only 1 bit, is saved which tells that Foo2.bar() is the method that was acutally called.
In previous versions of Chronon these method calls would have generated over 128 bits of data per call. In Chronon 3, they generated 1 bit or no data at all.
Thus you can get a glimpse of what a huge performance benefit this is.
The other thing we have done is to make use of non-heap memory as much as possible. So most of the recording data, and things like compression, etc are all done natively and dont impact the heap of your java application and thus dont impact the GC.
Another new feature you’ll want to try out is Per Thread Time , allowing you you to focus on specific thread instead of the entire system. You get to see this in the Stack view too. Focus is everything – if you know of a troublesome thread, you can forget about the rest.
Also you can split recordings at any time on the server, instead of waiting for the Recording Server to split them for you.
Chronon have offered JavaLobby readers a special 10% discount to use when purchasing personal licences of Chronon, using the JAVALOBBY coupon code
In the future, you can expect closer releases of Chronon, where the prediciton plug-in model will be continuously added to. The more predictions that Chronon provide will improve the performance.
As always, Chronon are listening to what users want in order to define the feature set for the next release. You can expect to see support for Java Collections sometime soon, another much requested feature, while the Recording Server will have new features to help with Ops and Application Monitoring
I was recently contacted by the people at Applicasa to give their service a go, and see how it works for me. The company claims that you can create a backend for your application in under 10 minutes – challenge accepted!
The Fundamentals of Applicasa
In a nutshell, Applicasa allows you to easily power the server side of your mobile application, iOS or Android, using some simple online tools. You create a database of objects to store all your data and then you download an SDK so that you can access this data from your mobile application.
The great thing is that you can easily run push notifications for your app from the online tool.
Creating an App
First you’ll need to set up that database, which is simply a representation of your domain model for your application. Simply click on the Add Object button which allows you to describe a table containing all the fields of each object.
Looking at the blog, it seems that future versions of the tool will support a self import feature.
Once you done all the work on your database, click on the “Build Database” button to generate the complete backend for your app.
You’ll then need to decide on your target platform to download the SDK, all of which is straghtforward with detailed instructions to get you there.
You can test out all the individual calls that may be made to your service through a WS tool. This is a useful means of debugging potential issues.
The most impressive part for me though is the push notification support. It’s made as simple as possible, where you can send a simple message to all users of your application, or even schedule the notification for a later time.
Once you have a clear idea of what your model should look like, you can easily get everything set up within that 10 minutes. The generation of the SDK can take a few minutes, but apart from that the whole process is really smooth.
Pricing
Applicasa are running a Start App program where you can use the solution for free up to when you reach 100,000 downloads. After that you can move to one of the paid plans. The plans start at $49 per month up to $199 per month. If you do hit that 100K mark, you’ll be looking at moving on to the $199 plan.
Conclusion
Applicasa provides a really simple way of creating a backend for any mobile app and connecting via a simple API. Push notifications are made to be as simple as you’d have hoped them to be. I’m sure the service will continue to improve over time, but I’m unaware of any offerings available at the moment that make backend app development as straight forward as this.
The Startup App program is a low risk way of trying the whole thing out, with zero cost to you, until you actually become successful at 100K downloads.
For a concise overview of how Applicasa works, check out their promo video:
Oracle have been busy – they have released the latest update for Java 7 and JavaFX 2.2, introducing the first release of JavaFX Scene Builder. There’s good news for developers on Mac OS X, as they will have full availability of the release, and get auto-updates at the same time as those on Windows platforms.
Along with the good news for Mac owners, there is now a JDK for Linux on ARM v6/v7 so that you can get Java running on your Raspberry Pi. Henrick Stahl has more details about the ARM port.
Is the Oracle JDK port to ARM available in OpenJDK? No, and we are not planning on open sourcing it at this point.
I own a Raspberry Pi/BeagleBoard/PandaBoard. How do I get Java running on it? Make sure that you use a Linux distribution that uses the softfloat ABI, then download and install the Oracle JDK on it.
JavaFX is now fully integrated into the Java SE implementation from this release. There is also the essential addition of multi-touch support, and an application packager to make distributing new bundles easier.
The Scene Builder provides a visual layout tool to create your JavaFX user interfaces.
In other news, JavaOne attendees will be treated to performances by Pearl Jam and Kings of Leon at the Appreciation Event this September.
An article popped up today claiming that Facebook is investigating compiling PHP to run on the JVM. Until now, Facebook has been using a PHP-to-C++ cross compiler. But the addition of invoke dynamic to Java seems to have opened up a new possibility for Facebook.
Alexander Turner, the author of this article points out that using the Multi Language VM for PHP is somewhat analogous to what V8 has done for JavaScript: JIT compilation of interpreted languages shows a significant increase in speed. In fact, Alexander sees this as the beginning of the end for interpreters:
These are exciting times. Soon I expect interpretors and interpreted langauges to be confined to DSLs and all general-purpose coding to be running in a JIT environment or as up-front compilation. That will be good for companies, good for performance and good for the planet.
Either way, it’s good to see another of the major companies taking the JVM seriously. It could certainly take a long time for Facebook to get to a stage where they can have their code running on a VM unless they leverage the Quercus or Project Zero implementations.
Unknown is whether this is actually happening, but it brings up an interesting debate. If you had a Facebook-size codebase written in PHP, would you take this approach? Node.js would certainly be a more fashionable alternative.
