By Dan Rubel, Productivity Enhancer, Dart Editor team

Cross-posted from the Chromium Blog

Today's release of the Dart SDK and Editor is the first beta release, and contains performance and productivity improvements across the platform. This latest release helps Dart developers automate code evolution, produce smaller JavaScript code and deploy Dart web apps.

The Editor's analysis engine, responsible for reporting warnings and errors, is completely rewritten and is 20% faster at parsing and analyzing. Now, there’s no need to run all the unit tests just to discover a typo. The Dart Editor watches your back as you type.

In addition, Dart Editor makes it easier for developers to manage an evolving app. Some of the new features include:

• "Rename Library" refactoring
• "Convert Method to Getter" and "Convert Getter to Method" refactorings
• "Import Library" quick fix
• "Create Class" and "Create part" quick fixes

Code completion has also improved. For example, completion is now camelcase aware. Type iE and Dart Editor finds isEmpty.

Compiling Dart to JavaScript now results in smaller code. For example, some Dart programs that use reflection and HTML can compile to JavaScript that is 3.7x smaller than previous compilation sizes.

Dart VM performance has also improved. Compared against the previous release of Dart, DeltaBlue is 33% faster and Tracer is 40% faster. This release also includes full SIMD acceleration in Dart VM.

Finally, deploying a Dart web app is now easier, with the beta pub deploy command. It creates a directory with your app's code and assets and prepares it for hosting on your favorite web server. You can use this command from Dart Editor or the pub command-line utility.

That's just the highlights - there are more improvements across the platform. You can read the full release notes for more details and changes. You can download the latest version of Dart Editor, including everything you need for Dart development, from dartlang.org. We look forward to your feedback!

Written by Dan Rubel, Dart Editor Team

Posted by Scott Knaster, Editor

By Louis Gray, Program Manager, Google Developers Live

One year ago, we took the magic of Google I/O and brought it home with Google Developers Live (+GDL)  - engaging with our developer community all year round, live, from our offices around the world. Nearly 1,000 videos and several million views later, we’ve seen you connect with Googlers and industry experts every day, gaining knowledge, sharing insights, and getting feedback on how to create incredible apps and leverage Google’s tools.

Thanks to the combination of Google+ Hangouts and YouTube Live, you can now see our engineers face to face and gain up to the minute insights on +Android, +Google Chrome, +Google Cloud Platform, and many more.

But Google Developers Live is not just all Google products, all the time. It’s an interactive platform for innovative applications, design wizards and entrepreneurs. We’ve hosted initiatives like Women Techmakers, Google Top Geek from Mexico City, Android Design In Action and Root Access, and we hear directly from the minds behind applications many of us use every day.



It was on GDL where we saw Google Fellow +Sebastian Thrun introduce a new HTML5 course on Udacity. GDL debuted the Mirror API for +Project Glass. And it was on GDL where we first demonstrated YouTube API v3, went behind the scenes with Santa Tracker, and answered questions on the Blink rendering engine.

And when we returned to I/O last month, it was Google Developers Live with wall-to-wall broadcasts, featuring exceptional guests like Megan Smith of Google[x], Bradley Horowitz of Google+ and Hiroshi Lockheimer and Hugo Barra of Android.

While we love the live interaction, Google Developers Live is more than just live. Our archives make it easy for you to watch on your own schedule - in any order, on any product.

Although GDL is only a year old, we’re now broadcasting from Mountain View, New York, Sydney, Tokyo, Milan, Moscow, Buenos Aires, and many places around the world, to bring you the latest Google tools for developers in your time zone, in your language. And we’ve got a lot more planned. So make sure you don’t miss a show, by subscribing to Google Developers on YouTube and staying tuned to https://developers.google.com/live/.


+Louis Gray is a Program Manager on Google's Developer Relations Team, running Google Developers Live. He believes life is but a (live) stream.

Posted by +Scott Knaster, Editor

The paper MegaPipe: A New Programming Interface for Scalable Network I/O (video, slides) hits the common theme that if you want to go faster you need a better car design, not just a better driver. So that's why the authors started with a clean-slate and designed a network API from the ground up with support for concurrent I/O, a requirement for achieving high performance while scaling to large numbers of connections per thread, multiple cores, etc.  What they created is MegaPipe, "a new network programming API for message-oriented workloads to avoid the performance issues of BSD Socket API."

The result: MegaPipe outperforms baseline Linux between 29% (for long connections) and 582% (for short connections). MegaPipe improves the performance of a modified version of memcached between 15% and 320%. For a workload based on real-world HTTP traces, MegaPipe boosts the throughput of nginx by 75%.

What's this most excellent and interesting paper about?

When people first use neo4j they frequently start out by embedding it in a Java application but eventually they want to explore the graph in a more visual way.

One simple way to do this is to start neo4j in server mode and use the web console.

Our initial code might read like this:

public class GraphMeUp {
    public static void main(String[] args) {
        GraphDatabaseService graphDb = new EmbeddedGraphDatabase("/path/to/data/graph.db");
    }
}

or:

public class GraphMeUp {
    public static void main(String[] args) {
        GraphDatabaseService graphDb = new GraphDatabaseFactory().
          newEmbeddedDatabaseBuilder("/path/to/data/graph.db").
          newGraphDatabase();
    }
}

And to start our graph up in server mode we can use the WrappingNeoServerBootstrapper class which is packaged in neo4j-server so we first need to add that dependency:

 <dependency>
    <groupId>org.neo4j.app</groupId>
    <artifactId>neo4j-server</artifactId>
    <version>1.9</version>
</dependency>

public class GraphMeUp {
    public static void main(String[] args) {
        GraphDatabaseService graphDb = new GraphDatabaseFactory().
          newEmbeddedDatabaseBuilder("/path/to/data/graph.db").
          newGraphDatabase();
 
        new WrappingNeoServerBootstrapper((GraphDatabaseAPI)graphDb).start();
    }
}

If we then browse to http://localhost:7474/webadmin/ we’ll be greeted by a 404 error:

HTTP ERROR 404
 
Problem accessing /webadmin/. Reason:
 
    Not Found
Powered by Jetty://

sad panda

Until I came across this post on StackOverflow by Michael I didn’t realise that there’s actually another dependency that we need to include to get the web admin goodness!

To get things worked as we’d expect we need to include the following dependency:

<dependency>
    <groupId>org.neo4j.app</groupId>
    <artifactId>neo4j-server</artifactId>
    <version>1.9</version>
    <type>jar</type>
    <classifier>static-web</classifier>
    <scope>compile</scope>
</dependency>

I hadn’t come across the classifier attribute before but what this does is include the following JAR:

$ ls -alh  ~/.m2/repository/org/neo4j/app/neo4j-server/1.9/neo4j-server-1.9-static-web.jar
-rw-r--r--  1 markhneedham  staff   3.5M 17 Jun 11:28 /Users/markhneedham/.m2/repository/org/neo4j/app/neo4j-server/1.9/neo4j-server-1.9-static-web.jar

If we run our code again we should see the bright and cheery web admin interface and all is good with the world.

The team shows what they have completed.

Demonstrations are a platform for an Agile team (or teams) to interact with stakeholders in order to solicit feedback and direction from a broader audience. A demonstration satisfies three primary goals: communication, risk mitigation and to provide motivation.

Format for demonstrations vary from one implementation of Agile to another however the basics always include the team communicating the work that was completed during the sprint. The activity of communicating what has been completed allows the team to showcase the value they are delivering.  The act of sharing generally facilities a discussion of needs, desires, risks and concerns between the stakeholders and the Agile team which enriches the team’s knowledge.

Demonstrating how the team (scrum master, product owner and technical team members) developed the solution for the work units at the end of each sprint avoids many of the classic risks seen in waterfall projects.  One of risks the that a demonstration mitigates is the risk of surprising the stakeholders with a solution that does not fit their needs at the end of the project. Feedback helps the team and the organization avoid building throw away projects by continually validating the direction.

Demonstrations provide a vehicle to generate or reinforce team motivation. Demonstration allow the team to publicly showcase the work they have completed which generates a sense of accomplishment.  A sense of accomplishment based on tangible results is a type of a feedback loop that helps build team confidence and while creating or reinforcing motivation. My professional observations of teams strongly suggests that motivation and confidence are directly related to productivity and quality.

Demonstrations are a tool to generate conversation about what is being delivered.  Because a demonstration occurs at the end of every sprint the team will continually be demonstrating the value they are delivering which reinforces confidence and motivation. The act of demonstrating value provides the team with a platform for collecting feedback that will help them stay on track and focused on delivering what has the most value to the business.

 

I have been talking about better conferences several times, but I’ve decided to stop doing that. A recurring theme at the DARE conference in Antwerp was:

Dare to be the change you want to see.

I want people to organize better conferences. Therefore, in order to find out what makes a great conference, I have decided to help the organizers.

An Event with a Purpose

Many conferences are organized around a single method or movement, such as Agile conferences, Scrum conferences, Kanban conferences, or Lean conferences. But methods and movements come and go. I believe it makes more sense to organize events around a purpose. For DARE the purpose is clear:

Dare to do something in order to enjoy better work. (Increase organizational performance and individual happiness.)

By organizing events around a purpose, we can invite representatives from any number of methods and movements, including Culture Hacking, Stoos, Design Thinking, Beyond Budgeting, Vanguard, Lean Startup, and many more… For DARE, it’s about the goal, not about the method.

It’s the Little Things

I am convinced that conferences can become great because of tiny little things. At DARE in Antwerp we had a barista making fantastic coffee. Instead of ugly conference bags full of sponsor crap we had a goodie mountain with valuable books and software licenses that people could choose an item from. And instead of boring badges we had brilliant buttons.

People also seemed to appreciate the regular newsletters, the conference app, the happiness doors and the great posters. But most important were the games, good wi-fi and fantastic catering. To top it all we had surprising speakers and controversial topics gathered together in an unconventional venue.

Faster Feedback Cycle

Maybe it is no surprise that some people said, “Looking forward to DARE 2014!” But why should we organize a conference only once per year? An iteration of one year is a very slow feedback cycle!

That is why I’m convinced we should have more DARE conferences, in different parts of the world. There should be a shorter feedback cycle, which enables organizers to learn faster and make each next one better.

Support from Happy Melly

Each next DARE conference can only be better if the same team is involved in the organization. That’s why Maarten Volders, Vasco Duarte, yours truly and our fellow organizers at Happy Melly are turning our experiences into a new service. When you turn your conference into a DARE event, you get access to our services.

This could mean: a great looking website, access to speakers and sponsors, a professional app, posters and other marketing materials, templates for contracts, game materials, newsletters, goodies, supplies, press coverage, and a direct line to Maarten, our conference wizard.

At least, that’s the idea! But this might change.

We’re just getting started. {8-)

Feedback on DARE

At the time of writing the average rating of the conference by participants is 8,5 (out of 10). No less than 88% percent of respondents say it is likely, very likely or extremely likely that they will recommend DARE to friends or colleagues. The Net Promoter Score of the DARE conference is 62%…

Feel free to contact me if you want to know more.

We’re pleased to announce Composer support for PHP applications.

This has been one of our most requested features, and should make it even easier for you to manage your apps. If you’re already using Composer, you can dive right in. If not, now is a great time to try it out. We recommend Composer for all PHP apps!

What is Composer?

Composer is a popular dependency manager for PHP. With it, you can specify project dependencies in a composer.json file and Composer will automatically handle the rest. For more information about Composer, take a look at the project website.

Why is It Useful?

Composer allows you to manage third-party dependencies separate from your code, decluttering your repository. What’s more, it makes updating your dependencies a snap. Just run composer update and Composer will fetch the latest compatible versions.

How Can I Use It?

Using Composer with Engine Yard is very simple. We’ll detect the presence of a composer.lock file in your repository, and automatically install your app’s dependencies. To get started with Composer for Engine Yard, take a look at the documentation.

The post Announcing Composer Support appeared first on Engine Yard Developer Blog.

An awkward moment occured while I was demonstrating property-based testing during my workshop at the XP2013 conference. Working out what went wrong surfaced an interesting difference between driving development from properties and from examples. When working from examples, we start with specifics and then generalise, by adding contradictory examples. With property-based tests it seems better to start with very general properties and then specialise. The code I was writing to demonstrate property-based testing was a function to calculate the surface area of a 3D cylinder. The test I wrote was: @forall(r=floats(), h=floats()) def test_cylinder_area(r, h): c = cylinder(r,h) end_area = pi * r**2 end_circumference = 2 * pi * r side_area = end_circumference * h assert_that(c.area, 2*end_area + side_area) And the code to make it pass: class cylinder: def __init__(self, radius, height): self.radius = radius self.height = height @property def area(self): return 2 * pi * self.radius * (self.radius + self.height) Not a great example of a property, I admit. I was trying to demonstrate how a property-based test more clearly expresses a property than a lot of examples that triangulate the property. For the purposes of demonstrating iterative development, I then threw a new feature into the mix: the system does not allow 2D or 1D shapes, so the area should be 0 when r=0 or h=0. The constraint for r=0 is covered by the existing property, but a change is required for the case when h=0. So, I added an additional property test: @forall(r=floats(), h=always(0))) def test_zero_height(r, h): c = cylinder(r,h) assert_that(c.area, equal_to(0)) And I made that test pass by adding a conditional in the cylinder's area property: class cylinder: def __init__(self, r, h): self.r = r self.h = h @property def area(self): if self.h == 0: return 0 else: return 2*pi*self.r*(self.r + self.h) However, to my embarassment, I had forgotten to change the test_cylinder_area test to ignore the case when h = 0, but it still passed! What's going on? The problem is that the floats() generator is so unlikely to generate a height of zero that the test_cylinder_area property was never applied to a combination of r and h that would have hit the special case for zero height. Even worse, using floats() to generate radius and height is wrong. Floats() can generate negative values, which can result in nonsensical negative areas. But the calculation of the expected area in the test_cylinder_area property allows the area to be negative. My tests should only generate floats greater than or equal to zero for the radius and height. In factcheck, the floats() generator can be parameterised by a lower bound: def pos_floats(): return floats(lower=0) This will kill two birds with one stone, because when a lower bound is specified factcheck will always generate the lower bound, and that will make the current implementation of test_cylinder_area fail for the h=0 case as it should. But that's not good enough. Before fixing the generators, I want to see a test fail because they are incorrect. The fact that I could write nonsensical properties and see them pass makes me think that I made too large a step at the start. I should have started by writing simpler, but more general, properties, that would then act as a safety net, double-checking the more specific but complex properties and implementation I added later. A simple property that catches my mistake is that the area must always be positive: @forall(r=floats(), h=floats()) def test_cylinder_area_is_positive(r, h): assert cylinder(r,h).area >= 0 That fails, as it should. Now I can start fixing the generators. Fixing the generators highlights another mistake I made. I used the primitive floats() generator wherever I needed to generate heights and radii. This makes changing the tests to use pos_floats() instead of floats() rather tedious. I should have used generators to capture domain knowledge. Now is a good time to fix that too: radii = pos_floats heights = pos_floats Now I can change the existing properties to use radii() and heights() generators instead of floats(): @forall(r=radii(), h=heights()) def test_cylinder_area_is_positive(r, h): assert cylinder(r,h).area >= 0 @forall(r=radii(), h=heights()) def test_cylinder_area(r, h): c = cylinder(r,h) end_area = pi * r**2 end_circumference = 2 * pi * r side_area = end_circumference * h assert_that(c.area, 2*end_area + side_area) @forall(r=radii(), h=always(0))) def test_zero_height(r, h): c = cylinder(r,h) assert_that(c.area, equal_to(0)) Finally the incorrect test_cylinder_area property fails as it should. I can fix it by specifying that it only applies to heights that are greater than zero: @forall(r=radii(), h=heights(), where=lambda h: h > 0) def test_cylinder_area(r, h): c = cylinder(r,h) end_area = pi * r**2 end_circumference = 2 * pi * r side_area = end_circumference * h assert_that(c.area, 2*end_area + side_area) I think that starting with a small but generic first property is key to using property-based testing with incremental design and a significant difference to using example-based testing. When working from examples, we start with specifics, initially a single specific example, and generalise, by adding contradictory examples, either to "triangulate" a property with examples or to add new behaviour. In fact, if very strict about TDD, you avoid making a distinction between the two. With property-based tests it seems better to start with very general properties and then specialise. The general properties act as a safety net in case you get later properties or generators wrong.

You know your product is doing well when most of your early blog posts deal with the status of the waiting list of hundreds of thousands of users eagerly waiting to download your product. That's the enviable position Mailbox, a free mobile email management app, found themselves early in their release cycle. 

Hasn't email been done already? Apparently not. Mailbox scaled to one million users in a paltry six weeks with a team of about 14 people. As of April they were delivering over 100 million messages per day.

How did they do it? Mailbox engineering lead, Sean Beausoleil, gave an informative interview on readwrite.com on how Mailbox planned to scale... 

Many years ago, I started a job as a contract manager, and it became clear I had a big problem. I had developers who knew one area of the code well. I had testers who knew not much of any area of the code well, even though they had worked for the organization for many years. Why? They had been shuffled from one project to another almost every month for years.

The writers had more domain expertise than anyone, because they had learned the product from end to end. What was I going to do? This project needed to finish in eight weeks, I needed to hire my replacement, and the people were shell-shocked from one manager after another. I was the fourth Director of Software Development in six months.

I decided to make a project portfolio, and rank the projects to know which projects were first, second, and third. I knew about this first project, but what was second and third? I was sure we had more crises, waiting.

Next, I asked people what they wanted to work on. I was sure that people could select their areas of responsibility, and it would work out. This is before we had agile teams. I was using a staged delivery lifecycle, so we had cross-functional teams and we worked by feature.

Next, I asked the teams to develop their deliverables in two-week chunks: what deliverables, as in features, could they deliver in the next two weeks, working as a cross-functional team?

The teams started to work together. They started to work across the code, not just in one area of the code. It wasn’t perfect, but it was working. The testers expanded their knowledge, because they were able to focus on the entire product. The developers learned the product end-to-end. The writers were happier, because people answered their questions.

About three weeks into this, a crisis happened with the second-ranked project. A senior manager wanted to yank a bunch of people off the top-ranked project and put them onto the second ranked project. He told me I had to give him people.

“No. I have no one for you.”

“But you work for me.”

“Yes, I work for the organization. But this project, the one that everyone is on, is more important than your project. So, I have no one for you, and I won’t for another two weeks. Unless I hear from the CEO that your project is more important than this one. In that case, we will stop working on this one, and everyone will work on your project.

We only have eight people. We can’t multitask. We can only work on one project at a time. Moving people off and onto projects as if they are chess pieces doesn’t make sense. This top-ranked project has two more weeks to go, and then it’s done. When it’s done, I can assign all eight people to your project, no problem. But assigning them now? Craziness.”

Now, should I have called him crazy? That was darn close to a career limiting conversation. Don’t do that! But the rest of the conversation? Useful.

And that’s the topic of this month’s Management Myth #18: I Can Move People Like Chess Pieces. When you move people like chess pieces, you deny them the opportunity to learn domain expertise. You don’t manage the project portfolio, and you decrease the capacity of your organization. It’s all around bad.

Did I want to be nice to the senior manager? Of course I did. But, good management is not about being nice to everyone all the time. Much of management is about saying no when you have to. And, I really needed to say no.

With agile approaches, I would have had more options: I could have used iterations and sequenced the projects differently—maybe. But that would not have allowed the organization to release the top-ranked project in the next few weeks. It would have made the people feel horrible, as if I’d yanked the promised dessert away from them. Yes, the project was that close to completion.

While you can move people as if they are chess pieces, it’s rarely a good idea. You want to leave people with project teams, to let them create a solid team—that’s the forming, storming, norming part. And, you want to keep people on a product long enough that they develop significant domain expertise in the product. When they become bored and ask to move, then they will tell you in a one-on-one that it’s time to move.

In the meantime, don’t move people as if they are chess pieces. People need to develop mastery over their work. They need the autonomy to select the areas of their work that they will develop domain expertise in. They need to feel as if they have a sense of purpose about the work. Gee, it sounds as if I’m parroting Dan Pink, in Drive. I guess I am. When you commit to project teams, and leave people where they are, so they can learn the product and learn how to work with their teams, and let the work flow through the teams, you create an environment that allows for autonomy, mastery, and purpose. And, that’s part of what a great manager does.

With more than 500 pages, this book about the requirements process by Suzanne and James Robertson provides a lot of valuable material about on this crucial activity of software development projects. “Garbage in, garbage out” was what I used to hear at the beginning of my software development career and it is still true today.You will find this book useful whether you are working in a “just enough requirements” environment or if you have more stringent requirements about what your requirement should contain. Mastering the Requirements Process. Source: http://www.volere.co.uk/masteringrequirementsprocess.htm Read my ...

Demonstrations are not presentations.

Demonstrations, also know as Demos, are Agile’s mechanism to share what the team has been accomplished during the current sprint. The show and tell (a nod to the readers that went to kindergarten in North America) that is the base of the demo provides the team with a platform to describe what has been accomplished in a manner that is difficult to misinterpret. Demos build confidence and customer satisfaction.

Demonstrations occur on the last day of every sprint. Demonstrations show the stakeholders what has been accomplished during the current sprint. The goal is for the team to gather feedback from the stakeholders so that they build what is needed and what the team committed to doing at the beginning of the iteration. When sprint teams publicly commit to what they will accomplish then perform against that commitment they build confidence and satisfaction. The transparency created when the team shares its performance allows the team to rush toward feedback while selling progress.  Good demos include stakeholders interacting with the software so that everyone understands exactly what has been developed.

Demonstrations are the teams mechanism to gather feedback and to ensure they are delivering value. I believe that demos have two currencies. The first is working software and the second is feedback. Teams build cache when they say what they are going to do, do what they say and listen to how their stakeholders feel about what they deliver.

 

I was talking with a colleague recently about the following question:

“How do you accelerate business value?”

One of the key challenges in today’s world is accelerating business value.   If you’re implementing solutions, the value doesn’t start to get realized until users actually start to use the solution.

THAT’s actually the key insight to help you accelerate business value.

It’s adoption.

When you are planning, if you want to accelerate business value, then you need to think in terms of pushing costs out, and pulling benefits in.  How can you start throwing off benefits earlier, and build momentum?

With that in mind, you have three ways to accelerate business value:

1. Accelerate adoption
2. Re-sequence the scenarios
3. Identify higher value scenarios

Before you roll out a solution, you should know the set of user scenarios that would deliver the most business benefits.

Keep in mind benefits will be in the eyes of the stakeholders.

If the sequence is a long cycle, and the adoption curve is way out there, and benefits don’t start showing up until way downstream, that’s a tough sell.   And, it puts you at risk.   These days, people need to see benefits showing up within the quarter, or you have a lot of explaining to do.

1.  Accelerate Business Adoption

So one of the ways to accelerate business value is to accelerate adoption.    There are many change frameworks, change patterns, strategies and tactics for driving change.    Remember though that it all comes down to behavior change and changing behaviors.  If you want to succeed in driving change in today’s world, then work on your change leadership skills.

This approach is about doing the right things, faster.

2.  Re-Sequence the Scenarios

Another way to accelerate business value is to re-sequence the scenarios.   If your big bang is way at the end (way, way at the end), no good.  Sprinkle some of your bangs up front.   In fact, a great way to design for change is to build rolling thunder.   Put some of the scenarios up front that will get people excited about the change and directly experiencing the benefits.  Make it real.

The approach is about putting first things first.

3.  Identify Higher Value Scenarios

The third way to accelerate business value is to identify higher-value scenarios.   One of the things that happens along the way, is you start to uncover potential scenarios that you may not have seen before, and these scenarios represent orders of magnitude more value.   This is the space of serendipity.   As you learn more about users and what they value, and stakeholders and what they value, you start to connect more dots between the scenarios you can deliver and the value that can be realized (and therefore, accelerated.)

This approach is about trading up for higher value and more impact.

If you need to really show business impact, and you want to be the cool kid that has a way of showing and flowing value no matter what the circumstances, keep these strategies and tactics in mind.

The landscape will only get tougher, so the key for you is to get smarter and put proven practices on your side.

People that know how to accelerate business value will float to the top of the stack, time and again.

You Might Also Like

10 Big Ideas from Getting Results the Agile Way

10 Ways to Make Agile Design More Effective

Agile Methodology in Microsoft patterns & practices

Change Quotes

How We Adhered to the Agile Manifesto on the patterns & practices team

I was a little skeptical of the Dart language when Google first announced it.

When I looked at the syntax of the language I thought that it didn’t really seem to offer anything new.

Why create another language that is not very different than what we already have?

How is this actually much better than JavaScript?

But after having worked with Dart now for quite awhile and producing a Pluralsight course on Dart, I’ve completely changed my mind.

The Dart language is awesome!

What makes the Dart language so awesome is all the little subtleties the language designers added to the language, not any major new concepts or ideas.

When I started writing Dart code it felt exactly right.  It felt like all the little annoyances that I had with languages like C#, Java and JavaScript were removed by the Dart language.

In fact, the real beauty of Dart is that if you already know C# or Java and JavaScript, you’ll probably be able to learn enough about the Dart language to be productive in Dart in less than an hour.

Before I show you just how easy it is to get started, let me briefly tell you what the Dart language is:

• Object oriented.  Everything is an object including primitives and nulls
• Optionally typed.  You can add type annotations which static checking tools can use to help you find errors in your code, but you don’t have to use them.
• Interpreted.  Dart is run in a VM, but it is not compiled first.  Round-trip time for making changes is very short.
• Compatible with JavaScript.  You can compile your Dart code to JavaScript and run Dart applications in any modern browser.
• FAST!  Dart is very fast, much faster than JavaScript in just about every test.

Some cool language features that I like about the Dart language:

• Mixins.  Instead of using inheritance, you can use a mixin to add functionality to a class without directly inheriting from another class.
• Isolates.  Instead of threads, the Dart language uses isolates for concurrency.  Isolates can’t actually share any memory, they pass information though messages.  It is very hard to shoot yourself in the foot.
• Simplified built-in types.  Numbers can be either int or double, and you can just use num, if you don’t care.  Lists and maps can be declared as literals.  An array is just a special case of a list.
• Functions are first-class objects.  You can pass them around just like any other object.  There is even a lambda-like short-hand for creating a one-liner function.
• Top level functions and variables.  Don’t want to put a function or variable in a class?  Good, you don’t have to.  In the Dart language, you can declare them anywhere you want.
• Simplified classes.  There is short-hand for declaring constructors that assign parameters to class members.  Class members don’t have protected, private, public.  Member variables are automatically properties.
• String interpolation.  No more string format methods, just use the $variableName in a string to have its value expanded.

Getting setup with the Dart language

Ready to get running in 5 minutes?

Ok, read on.

Step 1: Go to http://dartlang.org and click “Get started.”

Step 2: Download Dart (64-bit or 32-bit.)  Unzip the file and copy the “dart” folder to where you want Dart installed.

This folder will contain the Dart Editor, the Dart SDK and the Chromium web browser which has a built-in Dart VM.

Step 3: Run DartEditor.exe

That is it, now you are ready to rock some Dart code!

Creating your first Dart language App

The Dart language can actually be used outside of a browser, just like you can use JavaScript with Node.js.  But, most developers will probably want to use Dart the same way we use JavaScript in a web application today.

I’m going to walk you through a real simple example that will show you how to create a basic Dart application that is able to respond to a button click and manipulate some DOM data.  For more advanced examples, you can check out my recently released Pluralsight course on Creating Web Applications with Dart. (I will plug this one more time before this post is over… wait for it…)

Step 1:

Go to File –> New Application.

Fill in your application name.  I’ll call mine HelloWorldDartWeb.

Leave “Generate sample content” checked.

Select “Web application.”

Step 2:

Open the helloworlddartweb.html file and clear out everything in the body element except for the two script tags at the bottom.

The first script tag imports our actual Dart file, just like you would use to add JavaScript to a page.

The second script adds Dart support to the browser.

Step 3:

Add the following HTML to the body tag in the helloworlddartweb.html file:

 <button id="theButton" >Press Me!</button>
 <div id="resultDiv"></div>

This will just create a button and a div.  We are going to add some Dart code to respond to a button click and populate the div with some text.

Step 4:

Open the helloworlddartweb.dart file and clear out everything in main() and delete the reverseText function.

Notice that there are only two things we really will need in our .dart file.  Just an import ‘dart:html’, to import that html library for Dart, and the main function, which executes as soon the DOM content is loaded on the page.

Step 5:

Edit the helloworldweb.dart file to make it look like this:

import 'dart:html';

void main() {
  var button = query("#theButton");
  button.onClick.listen(addResult);
}

void addResult(Event e) {
  var resultDiv = query("#resultDiv");
  resultDiv.text = "You clicked the button";
}

This code simply gets the button using a CSS selector.  It uses the query function to do this.

Then we register the addResult function as an event handler for the onClick event for the button.

In the addResult function, we simply query for the resultDiv and change its text.

After you run this example, you should see a result like this:

Step 6:

Now change the Dart code to look like this:

import 'dart:html';

void main() {
  query("#theButton")
    .onClick.listen(
        (e) => query("#resultDiv").text = "You clicked the button!"
    );
}

Try running the code again and you should see it works exactly as before.  Here we just shortened the code to a single line by using the short-hand function syntax.

Going further with the Dart language

So, that is just the basics of Dart.  I wanted to show you how to get started really quickly, but I am sure there is more you will want to learn about Dart.

We can of course do much more with Dart, especially when building web applications.  There is a Dart Web UI library which can be used to do templating and data binding so we can simplify our Dart code even further.

The language itself is pretty simple.  Most C# and Java developers, as well as JavaScript developers, should be able to read and understand Dart code without any assistance.  But here is a link to an overview of the language.

If you are looking for a more in-depth coverage of the Dart language and want to see how to build a real application with Dart, check out my Introduction To Building Web Applications With Dart course on Pluralsight, where I go over the entire language and guide you through building a real application, as well as cover some of the more advanced features like mixins and isolates.

Also, I could only find two books on the Dart Language.

• Dart in Action by Chris Buckett
• Dart: Up and Running by Kathy Walrath and Seth Ladd

I don’t know if Dart will end up replacing JavaScript, but I do think Dart has the potential.  It really is an awesome language that is fun to develop in.

That is strong praise coming from me, since I really tend to dislike dynamic languages.  The creators of Dart have really done a good job of creating a language that is succinct, fast, easy to work with and has the best advantages of strongly typed languages with all the flexibility of dynamic languages like JavaScript.

Get Up and CODE and YouTube Videos

For those of you who frequent my blog and are looking for my latest Get Up and CODE podcast episode and YouTube video for the week, I have a bit of an announcement.

I am going to start posting these blog posts every Monday.

The YouTube videos will be going up every Wednesday.

The Get Up and CODE podcast will be coming on every Friday.

When my new website design is done, you’ll be able to find the latest episodes of each on the side bar, so I’ll stop including them in each weekly post.

But here is last week Get Up and CODE, where Iris and I talk about basic weight training.

Get Up And Code 006: Basic Weight Training

jQuery(document).ready(function($) { $('#wp_mep_1').mediaelementplayer({ m:1 ,features: ['playpause','current','progress','duration','volume','tracks','fullscreen'] ,audioWidth:400,audioHeight:30 }); });

Follow @jsonmez !function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,fjs);}}(document, 'script', 'twitter-wjs');

The post Getting Started With Google’s Dart Language appeared first on Simple Programmer.

There is a quote from George Box that is used - misused actually - by many populist blogers and authors that goes like this...

All models are, some are useful

Of course this quote is used to avoid asking and answering questions around models, forecasting, and assessment of possible future states of systems, a project being a system.

The actual quote is from Science and Statistics, George E. P. Box, Journal of the American Statistical Association, December 1976, pp. 791-799.

So the actual reading would suggest "all model are wrong" ... and the correct answer cannot be obtained by making the model more elaborate. A simple model is needed.

But how simple? That's always the challenge. 

The nonsense that #NoEstimates is the answer is of cource just as foolish as overparameterized and overelaborated models. This of course is lost on both sides of the modeling discussion. 

Related articles Models ... Calling BS on "All Models Wrong" Everything is a Random Variable Models All models are wrong

My father 2004. Thanks Dad!

June 16, 2013 is Father’s Day in the United States. Fathers have a huge impact on how we think about and react to the world. According to TheFatherhoodProject.org, children who have engaged fathers have greater problem solving competence and more empathy.

Our role as change agents is to help organizations deliver more value tomorrow than was possible today. In order to deliver on that role change agents solve problems on a daily basis. If you believe that your father is important in the capacity to deliver change then we need to say thank-you.

The ability to understand the emotions of those who are being asked to change, improves our ability to facilitate organizational change. Empathy is an ability we develop in childhood. Team leadership and collaborative decision making techniques works best if we understand how those around us are reacting and adapting to the changes we are facilitating. By helping develop empathy, fathers make us better change agents.

Whether you celebrate Father’s Day today or on another day it is more important to say thank you to your father for helping you to become the best change agent possible.  To my father…thank you for everything!

 

 

Welcome to the Software Process and Measurement Cast 242   

The Software Process and Measurement Cast 242 features my interview with Timothy Grayson. Timothy is the author of The Spaces In Between. We discussed discovery, learning and innovation!

Mr Grayson's Bio . . .

Timothy Grayson exposes simple truths and envisions a better future when smart people stop getting railroaded by intellectual bullies. In his latest book, The Spaces In Between, he encourages different thinking and new perspectives. For 25-years, Timothy has innovated in software, investment management, online travel, and postal services. He’s been a recognized thought leader in digital identity, direct/mobile marketing, and digital geo-location. An irregular blogger at recursiveProgress, Timothy’s writing has appeared in many magazines, newpapers, and online forums. He speaks often for organizations and at conferences on innovation, the future of IT, and better futures.

Email: enquire@timothygrayson.com
Follow Timothy on Twiitter: @graysonicles

Buy the Kindle edition at 

• The Space In Between (Kindle)

The Software Process and Measurement Cast has a sponsor . . .

As many you know I do at least one webinar for the IT Metrics and Productivtity Intstiute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI's mission is to pull together the expertise and educational efforts of the world's leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. THe ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars.  The Software Process and Measurement Cast recieves a fee if you sign up this link.  All revenue our sponsors goes for bandwidth, hosting and new cool equipment to create more and better content for you!  Support the SPaMCAST and learn from the ITMPI!

THe Software Process and Measurement Cast is a proud member of the Tech Podcast Network.  Check out the Software Process and Measurement and other great casts like The ElegantWorkflow.Com!  http://ow.ly/lQO1r 

Do you have a Facebook account?  If you do please visit and like the Software Process and Measurement Cast page on Facebook. http://bit.ly/16fBWV

The Daily Process Thoughts is my project designed to deliver a quick daily idea, thought or simple smile to help you become a better change agent. Each day you will get piece of thought provoking text and a picture or hand drawn chart to illustrate the idea being presented. The goal is to deliver every day; rain or shine, in sickness or in health or for better or worse! Check it out at www.tcagley.wordpress.com. 

Shameless Ad for my book! 

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: "This book will prove that software projects should not be a tedious process, neither for you or your team."

NOW AVAILABLE IN CHINESE! 

Have you bought your copy?

Contact information for the Software Process and Measurement Cast

Email:  spamcastinfo@gmail.com
Voicemail:  +1-206-888-6111
Website: www.spamcast.net
Twitter: www.twitter.com/tcagley
Facebook:  http://bit.ly/16fBWV

Next:

The Software Process and Measurement Cast 243 will feature my essay titled "What Is Agile." We all use the word but what does it really mean?  How should I act if I am agile?

Feedback loops help make planning more effective.

Hand Drawn Chart Saturday

Agile planning is layered and continuous throughout the life span of a project. The continuous nature of Agile planning provides a stream of feedback that makes making course corrections more effective. Agile release planning actively uses feedback loops from sprint / iteration planning and indirectly from daily sprint meetings.

Mike Cohn has described Agile planning as an onion with more strategic planning on the outside of the onion and the planning that occurs in the daily sprint meetings at the core of the onion. Each layer of the Agile onion includes planning and that planning reacts to the performance of the layers below.  Release planning provides sprint planning with information about the goal(s) of upcoming releases and the functionality that the product owner and stakeholders are anticipating. Sprint planning further breaks the goals and needs into tasks and activities. The team translates results into knowledge and information that is used to refine daily activities and is then used to refine the next iteration of sprint planning which in turn provides feedback to the release planning process. Each planning activity is influenced by results from next layer of activity.

Short iterations provide the ability to plan and then gather results that will either validate the plan or generate the impetus to change the plan. Feedback loops are an important part of ensuring that we continually adjust plans so that we get it right.

 

“We must become the change we want to see.” – Mahatma Gandhi

I’m a fan of continuous learning and skills development.   The challenge, though, aside from figuring out which training is worth it, is to first and foremost build a foundation that makes all the rest of your training actually worth it.

The key is to first build a rapid learning foundation that helps you absorb all the other training in a more effective way.

I’ve wasted a lot of money over the years testing and trying out various programs that made great promises.   But, during my trials, I’ve also found programs that really do produce outstanding results.   Of course, like anything, you get what you put into it, but some personal development programs are clearly based on better principles, patterns, and practices.  

That’s the gold, and we have to dig deep to find it among the sea of mediocre personal development programs.

Just last night, I was sharing with a friend, how to read 10,000 words a minute (I’m not there, yet.)   I was explaining the process of training to read without subvocalizing (which slows us down, big time … after all, you don’t want the voice in your head to sound like a chip monk, but you don’t actually have to internally vocalize words for your mind to absorb the content.)   Another key is developing high speed imaging skills, where you glance at information and absorb it.  Again, this doesn’t come naturally to most people so you need to train for it.

I realized this personal development program alone has paid me back so many times in so many ways and saved me so much time over the years, whether it’s processing email or devouring books.  I shared with my friend that I don’t have a lot of time to read books, but I’ll use a few hours to read 3-5 books a week, as well as often write up in-depth reviews.  He was amazed, and commented that he’s got a large book pile that he’d like to chomp through.

That’s just one of my secrets that has helped me leap frog in terms of rapid learning and saving massive amounts of time on a daily basis, and being to use my brain for other things than getting mired in walls of text.

But there are more.  

In fact, today I decided to share 3 personal development programs that give you an edge in work and life.    I’ll bottom line it for you here, that the three personal development programs are 1)  Personal Power, by Tony Robbins, 2) The Personal Mastery Program, by Srikumar S. Rao, and 3) Lead the Field, by Earl Nightingale.

In my write up, I shared quick stories on how each of them has helped me gain specific advantages in work and life.  In fact, some almost seem like unfair advantages because of the results they produced.

If you are looking to find the difference that makes the difference, or get an extreme advantage in our ultra-competitive world, then these 3 personal development programs should really help you out.

BTW – here is a tip that I often share when it comes to competition.   While you can draw inspiration from your “competition,” the best way to compete is to actually compete with yourself.   Whether that means pursuit a path of relentless excellence, or simply pushing yourself to higher ground, that’s where your breakthroughs happen.

Here’s to you and your ability to be awesome at life.

The neo4j docs have a few examples explaining how to to write cypher queries dealing with path ranges but an interesting variation that I came across recently is where we want to find the individual hops in a path.

I thought the managers that Chelsea have had since Roman Abramovich took over would serve as a useful data set to show how this works.

So we create all the managers and a ‘SUCCEEDED_BY’ relationship between them as follows:

CREATE (ranieri {name: "Claudio Ranieri"})
CREATE (mourinho {name: "Jose Mourinho"})
CREATE (grant {name: "Avram Grant"})
CREATE (scolari {name: "Luiz Felipe Scolari"})
CREATE (wilkins {name: "Ray Wilkins"})
CREATE (hiddink {name: "Guus Hiddink"})
CREATE (ancelotti {name: "Carlo Ancelotti"})
CREATE (villasBoas {name: "Andre Villas Boas"})
CREATE (diMatteo {name: "Roberto Di Matteo"})
CREATE (benitez {name: "Rafael Benitez"})
 
CREATE (ranieri)-[:SUCCEEDED_BY]->(mourinho)
CREATE (mourinho)-[:SUCCEEDED_BY]->(grant)
CREATE (grant)-[:SUCCEEDED_BY]->(scolari)
CREATE (scolari)-[:SUCCEEDED_BY]->(wilkins)
CREATE (wilkins)-[:SUCCEEDED_BY]->(hiddink)
CREATE (hiddink)-[:SUCCEEDED_BY]->(ancelotti)
CREATE (ancelotti)-[:SUCCEEDED_BY]->(villasBoas)
CREATE (villasBoas)-[:SUCCEEDED_BY]->(diMatteo)
CREATE (diMatteo)-[:SUCCEEDED_BY]->(benitez)
CREATE (benitez)-[:SUCCEEDED_BY]->(mourinho)

We want to write a query which will return the ‘SUCCEEDED_BY’ pairs starting from Claudio Ranieri and working down.

We might start out with this query which starts from Ranieri and goes all the way down the tree finding the next successor:

START m = node:node_auto_index(name="Claudio Ranieri") 
MATCH path = (m)-[rel:SUCCEEDED_BY*]->(successor) 
RETURN EXTRACT(n IN NODES(path): n.name)

==> +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
==> | EXTRACT(n IN NODES(path): n.name)                                                                                                                                                               |
==> +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
==> | ["Claudio Ranieri","Jose Mourinho"]                                                                                                                                                             |
==> | ["Claudio Ranieri","Jose Mourinho","Avram Grant"]                                                                                                                                               |
==> | ["Claudio Ranieri","Jose Mourinho","Avram Grant","Luiz Felipe Scolari"]                                                                                                                         |
==> | ["Claudio Ranieri","Jose Mourinho","Avram Grant","Luiz Felipe Scolari","Ray Wilkins"]                                                                                                           |
==> | ["Claudio Ranieri","Jose Mourinho","Avram Grant","Luiz Felipe Scolari","Ray Wilkins","Guus Hiddink"]                                                                                            |
==> | ["Claudio Ranieri","Jose Mourinho","Avram Grant","Luiz Felipe Scolari","Ray Wilkins","Guus Hiddink","Carlo Ancelotti"]                                                                          |
==> | ["Claudio Ranieri","Jose Mourinho","Avram Grant","Luiz Felipe Scolari","Ray Wilkins","Guus Hiddink","Carlo Ancelotti","Andre Villas Boas"]                                                      |
==> | ["Claudio Ranieri","Jose Mourinho","Avram Grant","Luiz Felipe Scolari","Ray Wilkins","Guus Hiddink","Carlo Ancelotti","Andre Villas Boas","Roberto Di Matteo"]                                  |
==> | ["Claudio Ranieri","Jose Mourinho","Avram Grant","Luiz Felipe Scolari","Ray Wilkins","Guus Hiddink","Carlo Ancelotti","Andre Villas Boas","Roberto Di Matteo","Rafael Benitez"]                 |
==> | ["Claudio Ranieri","Jose Mourinho","Avram Grant","Luiz Felipe Scolari","Ray Wilkins","Guus Hiddink","Carlo Ancelotti","Andre Villas Boas","Roberto Di Matteo","Rafael Benitez","Jose Mourinho"] |
==> +-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
==> 10 rows

That gives us all the combinations but unfortunately it includes all the previous successors as well so it’s not quite what we want.

We need to manipulate the query such that we have a list of all the managers and can then follow a single ‘SUCCEEDED_BY’ relationship to find their successor.

We could easily get that list of managers by following the ‘SUCCEEDED_BY’ relationship and getting the nodes on the other side but that would lead to Claudio Ranieri being excluded since he doesn’t have an incoming relationship.

To keep Ranieri we can make use of the 0 length path like so:

START m = node:node_auto_index(name="Claudio Ranieri") 
MATCH path = (m)-[rel:SUCCEEDED_BY*0..]->(mm) 
RETURN mm

==> +--------------------------------------+
==> | mm                                   |
==> +--------------------------------------+
==> | Node[8]{name:"Claudio Ranieri"}      |
==> | Node[9]{name:"Jose Mourinho"}        |
==> | Node[10]{name:"Avram Grant"}         |
==> | Node[11]{name:"Luiz Felipe Scolari"} |
==> | Node[12]{name:"Ray Wilkins"}         |
==> | Node[13]{name:"Guus Hiddink"}        |
==> | Node[14]{name:"Carlo Ancelotti"}     |
==> | Node[15]{name:"Andre Villas Boas"}   |
==> | Node[16]{name:"Roberto Di Matteo"}   |
==> | Node[17]{name:"Rafael Benitez"}      |
==> | Node[9]{name:"Jose Mourinho"}        |
==> +--------------------------------------+
==> 11 rows

If we now follow the ‘SUCCEEDED_BY’ relationship from our list of managers we end up with pairs of managers:

START m = node:node_auto_index(name="Claudio Ranieri")  
MATCH path = (m)-[rel:SUCCEEDED_BY*0..]->(mm)-[:SUCCEEDED_BY]->(successor)
RETURN DISTINCT mm.name, successor.name

==> +-----------------------------------------------+
==> | mm.name               | successor.name        |
==> +-----------------------------------------------+
==> | "Claudio Ranieri"     | "Jose Mourinho"       |
==> | "Jose Mourinho"       | "Avram Grant"         |
==> | "Avram Grant"         | "Luiz Felipe Scolari" |
==> | "Luiz Felipe Scolari" | "Ray Wilkins"         |
==> | "Ray Wilkins"         | "Guus Hiddink"        |
==> | "Guus Hiddink"        | "Carlo Ancelotti"     |
==> | "Carlo Ancelotti"     | "Andre Villas Boas"   |
==> | "Andre Villas Boas"   | "Roberto Di Matteo"   |
==> | "Roberto Di Matteo"   | "Rafael Benitez"      |
==> | "Rafael Benitez"      | "Jose Mourinho"       |
==> +-----------------------------------------------+
==> 10 rows

The code for this is available on the neo4j console if you’re interested in playing with it further.