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

Follow @jsonmez

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

Do you consider yourself a good salesman?

If you are like most programmers, you probably don’t.

But have you ever stopped to consider what “selling” and “sales” really are?

Have you ever taken the time to dissect the process of marketing and making a sale and tried to see how it applies to your own life and career?

It’s OK if you haven’t—most people haven’t.

I’m selling you right now

If you’ve made it this far, it is going well for me.  You probably decided to read this article because of the headline I created for it, “The One Thing You Don’t Know How To Do That You Do Every Day.”  Then, the questions I asked in the paragraphs above must have held your interest long enough for you to get to my sub-heading telling you that I am selling you right now.

You see, unless I am actively selling you with my words, you aren’t going to be reading this blog.  And, if you aren’t reading this blog, there really isn’t a point in me writing it.

This may not seem important, but the effects of a good sale are profound; especially when you magnify them by a huge number.

Imagine for a moment that this article lands in mainstream media and is featured on national media outlets—yes, a pipedream, I know, but bear with me for a moment.

What would happen to those ads over there on the right or at the bottom of this article?  How valuable would they suddenly become?

How many people would subscribe to this blog?  How many people would follow me on Twitter or check out the other things I am doing?

The difference between a thousand page views and a million page views is huge!

If I had the ability to “sell” these free words to millions of people each day, even my $0 priced product would have immense value.

When I am writing this blog post, it doesn’t “feel” like I am selling anything, but it is a mistake to think I am not.

I am selling you my ideas, my brand, my name and more.  You are paying me with the single most valuable asset you have… your time.  CHA-CHING!

You’re selling too

You may not think so, but everything you do in your life, every interaction, every word you speak, and even the clothes you wear are all part of one big sale.

It doesn’t even matter what your profession is, even if you are a programmer, you are selling something each and every day.

Take for instance the last conversation you had with your boss or your coworkers about what technology to use or what direction you should take to solve a certain problem.  If you had an opinion at all on what to do, you were in the process of negotiating a sale.  In this case you were selling your ideas.

Even the code you write is selling something.  The code you write should be conveying something about what it does and how it works.  If you can write the code elegantly, the reader of the code might not even be aware of the “selling” taking place.  Great code sells itself, it seems apparent, like there was no other way to write it.  Just like certain tech companies sell their products in a way that seems like they are obvious and your life wouldn’t be complete without them.

(If you lack the elegance of selling your code naturally, you may have to resort to hard sale tactics and add some comments to the code to describe in detail to the user what the code is doing and what its intent is.)

Your sale might not even be successful at all, as your reader may simply delete your code and replace it or ignore it completely.

Your code is also selling something besides meaning and understanding, it is selling your programming skills.  When someone reads code they know you have written, they are making certain judgments about you as a programmer, and even you as a person, believe it or not.

Now, you may not think this amounts to much or is very important—and it may not be—but most sales calls aren’t.  Professional salesman face a lot more “no”s than “yes”es, but for some salesman it only takes a couple of “yes”es to pay their whole years salary.

But it goes far beyond this as well.  Even the subtle things like the clothes you put on in the morning and how you sit in your chair, are influencing people around you and shaping their acceptance of everything you are selling.

What you post on Twitter, even what you like on Facebook, are all either working for or against the image you are trying to sell.

Why selling matters

So, you may be thinking, “ok that’s nice and all, and I kind of agree, but seriously, why should I even care?  So what if I am selling my “ideas” or my “personality” or something else, it doesn’t make a difference to my daily life.”

And that would be where you are wrong.

Do you know those kinds of people which seem to have everything go right for them?

Those people in which opportunity just seems to open its floodgates and rain on them pelting their heads with hailstones of success?

Guess what, most of those kinds of people happen to be excellent salesmen.

You see all those hundreds of sales calls that happen unconsciously every day of your life add up big over time.

If you are consistently “knocking it out of the park,” you are going to make a big impact and have huge amounts of influence.

This “influence,” which is really what sales is all about, will permeate all areas of your life.

If you have a large amount of influence, people will tend to like your ideas and agree with what you say.  They will want to follow you and they’ll be buying into your personal brand and your message, whether it be “save the whales” or “give me a promotion.” (Which is exactly why so many companies hire celebrities to represent their brand or product.)

If you lack influence, you can actually have the opposite effect and create a repulsion.  Think about the worst salesman you ever met.  Did he make you want to buy the products he was selling or did he actually turn you off from them and make you never want to buy those products?

It is the same with us, we can actually become repulsive to the point that we are working completely against ourselves.  We can get in situations where the more we try to promote our ideas or our vision of reality, the further away we actually push others from it.

Even if you are not trying to sell, you have to be good at it

So the bottom line is that we all need to learn how to sell and be better salesman, because even if we aren’t actively trying to sell something, we are still participating in the process of hundreds of sales transactions or more each day.

If we aren’t doing something to help make those sales transactions a positive influence for our interests, we may be inadvertently making them a negative influence.

You can be doing everything else right, but if you are selling wrong, you could be spinning your wheels or even going in reverse.

Now obviously, I’m not the best salesman I could possibly be, otherwise you’d probably be reading this post on the New York Times or CNN.com and not on simpleprogrammer.com, so you shouldn’t turn to me for sales advice.  (I’m just telling you that you need to develop the skill.)

But, I do have a few suggestions of where to get started.

First of all, a book that I always recommend over and over again that doesn’t seem to have anything to do with sales, but in actuality has a lot to do with sales is “How To Win Friends And Influence People” by Dale Carnegie.

And second, the place that makes sense to me to look next is Amazon’s Best Sellers in the Sales and Selling category.  (If you can’t figure out why to check this list, you may need more help than I can provide.)

By the way, I am working on a top secret specifically to help programmers and IT people learn to promote and sell themselves to help them increase their opportunities.

YouTube video for the week

And before I let you go, let me sell you on my YouTube video for the week about getting “punched in the stomach.”

Get Up and CODE: Episode 5, How to get 6-pack abs

And I’ve got one more free thing to sell, my latest podcast episode here:

Follow @jsonmez

The post The One Thing You Don’t Know How To Do That You Do Every Day appeared first on Simple Programmer.

Wow, I can’t believe I have actually reached the milestone of authoring 40 courses for Pluralsight.

My first Pluralsight course, Introduction to Android Development, was released on April 12th, 2011.  That is just over two years ago.

And my latest course, which makes number 40, if you count my contribution to the Design Patterns course, is Using Glimpse With ASP.NET, MVC4, and Entity Framework, which was published on May 5th, 2013.

The total hours of video content I have published in the 2 years from my first to my latest course is around 122 hours.  That means you could watch my Pluralsight videos for about 5 days straight.

Thank you

But before I tell you about what I learned from this experience, I just want to take a moment to say thank you.

I couldn’t have done this by myself and I am very thankful to everyone that helped me reach this important milestone.

First of all, you viewers of my courses who have been so supportive and encouraging and have made it possible for me to make a living at doing this, thank you.

I have interacted with many of you over email and Twitter and I have gotten lots of positive feedback and encouragement as well as some constructive criticism which has greatly helped me to improve my courses and to feel like I am doing something that is meaningful and helpful to many people.

So, sincerely, from the bottom of my heart, I thank you faithful viewers for watching my courses and I commend you on being the kind of developer that cares about learning and improving their skills.

I also want to thank Pluralsight and all of the staff and management of Pluralsight.  When I say that the folks at Pluralsight are some of the best people I have ever had the opportunity to work with, it is no lie. I have never met a more friendly group of energetic people that really care about what they do than the management and staff of Pluralsight.

The biggest lesson

You may be expecting that the biggest lesson I have learned during my super-speed course creation at Pluralsight is how to learn technologies quickly, and although I have certainly learned a great deal about doing that, the biggest lesson I have learned is that we can accomplish what we put our minds to if we are willing to not let anything stand in the way.

I don’t have any special skills or talents, besides my ability to say “Hi, this is John Sonmez from Pluralsight.”  I’m just a regular guy who works really hard and stays as focused as possible.

But, I didn’t always have the work ethic that I do today.

One thing that authoring courses for Pluralsight has taught me is that when you see an opportunity, you must seize it and make the most of it.

In order to do that, I had to drop many things in my life that I used to like to do, like watching TV or playing games, and focus on my opportunity.

And, yes, the opportunity to author courses at Pluralsight is an excellent opportunity, and I realize that not everyone has that opportunity.  But, we all have opportunities that sometimes are hard to see.  Opportunities that we need to seize and make the most of.

Many of these opportunities are once-in-a-lifetime, some of them come and go.  I’ve had opportunities in the past that I have let go, or I didn’t put my heart into, but with Pluralsight it was different.

I won’t bore you with the story of working a full time job for almost two years and doing Pluralsight courses every single night and weekend.  But, in order to seize this opportunity, I had to put in some hard work and be willing to make some sacrifices.

The reason why I mention this is because, if you are reading this post, you are probably the kind of programmer or IT professional who is already starting to seize an important opportunity to advance your career and skills.  I just want to encourage you that you can do whatever you want to do. You can be as successful as your willingness to work hard and believe in yourself will allow.

I hope that more than learning about a technology or development language from my courses, that I could teach you something much more valuable—the power of believing in yourself and not letting anyone put limitations on you.

Some other lessons

It is really difficult to summarize everything that I have learned over the past 2 years and 40 courses, because there is just so much, but here is a list of some of my biggest takeaways from this whole process.

• Learning a technology effectively can be broken into 3 steps
  • Create something simple with it
  • Learn the breadth of the technology to understand what there is to know about it.
  • Determine the most important high level topics to learn and only go into details when necessary, you can always fill in the details later
• Effective teaching is showing people something new in terms of what they already understand
• Have a goal, make a plan to get to it, and don’t deviate from it until it is accomplished
• If you fall off the horse get back on as soon as possible
• Encouragement feels better than criticism, but criticism if much more valuable
• Writing your thoughts out refines them and sands the jagged edges off of them
• Redoing work is much harder than doing it right the first time
• Nothing is the best.  No technology, no programming language, no way of doing things
• No matter how much you know, everyone and everything has something to teach you, if you will only listen
• It is very easy to type “HellWorld” and not notice until you’ve finished recording 30 minutes of video
• The right caption can make any image funny
• The key to efficiency a repeatable process
• Videos with just slides are much hard than videos with demos
• A good microphone adjusted properly makes a huge difference in audio quality
• Quotas are proactive, metrics a reactive

Onward to 50

So what’s next on my agenda?  Hitting 50 courses of course.

I’ve also been working with Iris Classon to produce a new podcast on programming and fitness called Get Up and CODE, because I am very passionate about fitness as well.

I’ll be working hard for the rest of this year to keep producing courses, since I still have a pretty big list of ideas, but after this year, I’ll probably be slowing down a bit, since I can’t keep up this ridiculous pace forever.

So thanks again for to everyone for all the support and encouragement, and to Pluralsight for this awesome opportunity.

My YouTube video for the week

Follow @jsonmez

The post After Completing 40 Online Training Courses for Pluralsight, What Have I Learned? appeared first on Simple Programmer.

What is your job title?

More importantly, what should your job title actually be?

There are quite a few job titles that describe people who write code for a living.

• Software Developer
• Developer
• Software Engineer
• Senior Software Engineer
• Programmer
• Coder
• Architect
• Software Architect

In my career I’ve officially held many of these job titles while being employed, but what your official job title is and what you call yourself are two different things.

Of course now I am self-employed, so I get to call myself whatever I want.

The job title debate

More than once, I’ve been involved in the debate over what people who write code should call themselves, what the difference is and what the different job titles actually mean.

Let me tell you something right now, before we even go any further:

Job titles don’t mean jack!

That’s right, you can’t know anything about a job or a person by their job title.

I’ve seen some companies call their most competent coders senior software engineer, I’ve seen others give that same group of people the job title architects, and I’ve seen some call them software developers.

Now obviously some job titles appear to have more clout than others, and obviously some titles would be more desirable for a software writing professional to have, but a job title alone doesn’t convey any real information.

Still, over twitter and occasionally over a blog post, I’ll see this long debate about which job titles mean what and what we should call ourselves.

The problem I have with almost all of these debates is that they are based on the ludicrous assumption that there is some actual real official designation of titles and their meaning that exists somewhere.

If there is one, I’d like to see it, because as far as I know we are just making this stuff up as we go along.

So what should programmers call themselves, then?

Good question… How about, oh I donno, programmers, maybe?

But wait John, I don’t just program computers!  I gather and analyze requirements, I design mock ups, write unit tests and I attend all kinds of meetings.  You may be a programmer, but as for me, I am a software developer.  Oh, and since I’ve been doing this for a while and I am awesome at it, I shall bestow upon myself the title of senior software engineer.

I get what you are saying; you’re important, you’re hot stuff, you don’t just program computers.

Heck, you probably spend a majority of your time not writing code.  Most programmers do.

But let me ask you this question.

What thing do you do that provides the highest value?

What is your most specialized skill set?

Now, not everyone is the same, but most people who write code for a living will have to admit that although they do many other things that add value and are required for their job, primarily what makes them valuable is their ability to program a computer.

If you took all the responsibilities and activities that senior software engineers do and you let someone else do them that could do all the functions of the job except for writing code, what would you call that person?

Most likely a business analyst or something around those lines, but it would seem a little silly to give them a title of senior software engineer.

At the same time, you could remove just about any other job function from a typical senior software engineer’s responsibilities and still easily call them a senior software engineer.

All this is to simply say that the thing of importance is the ability to program computers.

So again my answer to what you call yourself is the function you do that provides the most value: programming the computer.

(By the way, Amazon tends to think programmer is the right term, since the biggest book category under computers & technology is programming.)

It’s not what you do most that counts, it’s the most important thing you do that counts

If throughout our careers, we chose our titles based on what we did the most, we’d have titles like the following:

• Sr. Professional Emailer
• Customer Handler
• Pretender of Doing Hard Work
• Unit Test Writer
• Build Breaker Extraordinaire
• Meeting Engineer
• Legacy Code Maintainer
• Browser of the Webs
• Corrector Of Wrong People On The Internet

You may spend 90% of your time not writing code, but if writing code is really what your value primarily derives from, I see no good reason to call yourself something other than a programmer or a coder. (Although coder is a bit ambiguous and programmer is pretty much right on key.)

But wait, if I do that John, then people will think I just write code all day.  They won’t know that I have all these other skills that are required to develop software.

Once again, I get what you are saying.  I understand your concern, but it is ridiculous.

No one thinks that programmers just spend all day programming computers.

Just like no one thinks lawyers spend all day everyday in court arguing cases.

Most people will get that when you say “programmer,” you don’t mean that you just write code.

If you don’t believe me, then let me ask you again what it means when I say I am a software developer.

Does software developer or senior software engineer or architect more adequately describe the 50 job responsibilities of a programmer other than writing code?

I don’t think so.

But, at least the word programmer makes it clear to anyone, even someone who knows nothing about the field of software development, what the valuable thing you can do is.

It’s really not a big deal

Don’t get all worked up about this though.  I’m telling you right now because I know some of you are sure you understand the true meaning of the various programmer job titles out there.

I’m not asking you to call up your boss and demand that your job title be changed to just programmer.

No need to correct people when they call themselves software engineers or architects.  (And yes, I am grouping lowly software engineers in with architects, because if you are writing software, but you aren’t architecting it as well, you shouldn’t even call yourself a programmer, and if all you are doing is waving your magic wand and drawing architectures for others to implement, I’ve got news for you, you’re not adding any real value either.)

In fact, around this blog, you’ll find that I often say software developer, because it is a term I agree with and more people relate to it than programmer.  So, I’m not even that adamant about using programmer, myself.

I’m just saying, when someone asks you what you do for a living, spare them the grandiose speech and flowery words, just say “I’m a programmer” and leave it at that.  There is no need to say “I’m a software engineer”; to which they inevitably respond with, “oh, but what do you do?”  And of course you respond with some detailed description of what exactly software engineers do which could have all been summed up in the beginning by saying you were a programmer in the first place.

YouTube video for the week

Oh, and don’t forget to check out my YouTube video for the week, where I talk about why you should fake it till you make it.

Get Up and CODE

And here is the link to the latest Get Up and CODE episode, where Iris and I talk about healthy eating.  You can also listen to it below.

Follow @jsonmez

The post Your Job Title Is Wrong, Here Is What It Should Be appeared first on Simple Programmer.

If you are using ASP.NET, especially if you are using ASP.NET MVC, you need to be using Glimpse.

I’m currently working on a more exhaustive Pluralsight course on Glimpse,  (the course is now live!) but I thought I’d write up a quick getting started tutorial here.

What is Glimpse?

Perhaps you haven’t heard of Glimpse yet, or you are just a little unsure of exactly what it is.

Glimpse is basically an open source and free diagnostics platform for the web.  Right now it works best with ASP.NET and especially ASP.NET MVC, but it can be extended to other platforms as well.  There is already work started for a PHP version and even a Python port.

What Glimpse essentially does is let you see diagnostics information about what is happening on your server directly in your page through a small diagnostics window completely rendered in JavaScript.

Out of the box, Glimpse can show you all kinds of information about your MVC application, like what routes are registered, what the flow was through the MVC pipeline and how the models were bound.

(BTW, if you are looking to brush up on your ASP.NET MVC 4 skills or learn about ASP.NET MVC 4, I recommend Professional ASP.NET MVC 4.  Great book, top notch authors.)

Here is what the Glimpse window looks like on a page.

Glimpse is also fully extendable.

There are already plugins for Entity Framework, NHibernate, Ninject and many, many more

The best part about Glimpse is how easy it is to get setup.

I’ll walk you through the steps below.

Step 1: Get Glimpse from NuGet

All you have to do to get Glimpse installed is simply either:

• Open up the Package Manager Console and type “Install-Package Glimpse.Mvc4” (or “Glimpse.AspNet” if you aren’t using MVC)
• Or, right click on your references, select Manage NuGet Packages, then search for Glimpse and find the appropriate Glimpse package.

One you’ve done that, Glimpse will automatically add a few entries to your web.config for you.

Step 2: Turn on Glimpse

Turning on Glimpse is super easy.

Just launch your app and navigate to glimpse.axd.  Then, click “Turn Glimpse On” to set a cookie that will tell the Glimpse component running on the server to send you Glimpse data.

Go to glimpse.axd

Turn it on!

It’s that simple!

Step 3: Fire it up

Now all you have to do is navigate to any page in your application and you’ll see this little icon at the bottom right hand corner of the screen:

If you click the icon, you’ll see the Glimpse panel, which currently looks similar to the Chrome Dev Tools panel.

Using Glimpse

Each tab contains different diagnostics information about your application.

This data can be extremely helpful in troubleshooting problems and learning about exactly what is going on inside of MVC.

You can also find plugins that can be easily installed from NuGet.

For example, if you add the Entity Framework plugin, you’ll start seeing a tab that shows data about EF queries, like this:

I’m pretty excited about Glimpse and its future.  Anthony van der Hoorn and Nik Molnar, the two creators and main maintainers for Glimpse, have done an excellent job transforming how we get diagnostics information for web applications.

One of the things I find most exciting about this platform is how easy it is to extend.  In my upcoming Pluralsight course, (the course is now live!) I walk you through creating a Glimpse plugin, which is surprisingly easy.

So if you haven’t checked out Glimpse, what are you waiting for?  Go do it now, it will take you about 5 minutes to get setup.

What do you think?  Are you using Glimpse already?  Post a comment and let me know.

My YouTube video for the week: (This is not an ad!)

And here is the weekly Get Up and Code episode:

Get Up and CODE, Episode 2: Fitnesse And Nutrition Tips For a Busy Schedule

Follow @jsonmez

The post Getting Started With Glimpse In ASP.NET MVC appeared first on Simple Programmer.

Far too many Agile development projects fail. It is hard to even accurately measure the number of failures because so many software development projects end up “complete” and shipped, even though:

• They took far too long to build
• The quality of what we built was poor
• What was built was not what the customer wanted
• The cost to develop was more than it should have been

Over the years, I’ve worked on many different Agile teams and have consulted for and trained many teams on Agile development. In this time, I have found 5 common problems, that if not resolved, are very likely to cause a project to be a failure.

1. Not having a product owner

Of all the things that can cause an Agile software project to fail, not having a person that is ultimately the decision maker for the product being developed is the quickest way to ensure its demise.

It doesn’t matter if you are following Scrum, doing your own Kanban style project or something else; if you want your project to succeed, you need someone who can set its direction and make decisions about the product being developed.

Think about remodeling a kitchen. If you hired a bunch of contractors to come in and do the various jobs, like: plumbing; carpentry; flooring; etc, but you don’t have someone deciding what the actual finished kitchen should look like, you are going to get a random mess.

A few skilled contractors will probably be smart enough to find the right person to ask about what should be done, but it takes more than just making arbitrary decisions about where the cabinets should go to design a kitchen. You need someone to actually come up with a real design and vision and be able to modify that vision appropriately as the project progresses and problems inevitably occur.

It seems pretty nuts to spend a huge amount of money remodeling your kitchen, but not want to invest any time or effort in either designing the finished product or hiring someone to do it.

Yet, day in and day out, I see this exact behavior in software projects. I see companies investing huge amounts of cash in Agile development, but not appointing anyone to be the true owner of what is being built and to set the vision for it.

2. Not iterating

One of the key values that Agile development brings to the software development world is iteration.

What is iteration though?

You may think it means breaking your project into 2 week sprints or iterations.  While doing this can facilitate iterative development, it doesn’t mean you are actually iterating.

Confused? Let me explain.

The key to iterating is to develop a product a little bit at time. It would be accurate to describe the process of iterating on a product as evolution of a product.

Whether you believe in macroevolution or not, microevolution, or adaptation is a proven concept.  The idea behind evolution is that things change gradually over time. Those small changes add up to result in a big change.

Imagine how silly it would be if evolution worked the way most “Agile” software is built.

Imagine, if you will, a fish that swims in the ocean and has some little fish babies that are born with fully functional legs. Then, those legged fish babies grow up and have fish babies that have wings.

Probably the legs and wings wouldn’t do that fish much good, nor would they be designed properly, because instead of adapting and changing over time, they just suddenly appeared.

Features should not be built in a single sprint or iteration. It is as silly as legs showing up on a fish in a single generation.

Instead, features should be evolved and grow over time. A feature shouldn’t be pushed into a single sprint or iteration and then be done. A feature should start out small and develop and evolve over time as feedback is received and customers or the product owner tries it out.

Far too many times, I see Agile development projects mistake having iterations with actually iterating the development of the product.

Don’t try to ship a completed feature at once, let it evolve over time.

3. Not breaking things down small enough

I am a big proponent of breaking things down into small, easily digestible pieces.

The main reason why this is so important is because it prevents procrastination. Procrastination usually occurs when either we dread some large task that will be difficult or we don’t know what to do next.

If you can break a big project up into small parts, it will seem easier to accomplish and will have clear steps of progression.

I often see software projects where the person creating the backlogs or work items is not considering the work enough before giving it to the team.

I coined a term for these kinds of backlogs: fatlogs. Fatlogs are backlogs that are not broken down small enough and often are very vague in what needs to be accomplished.

Fatlogs are notoriously difficult to estimate and waste time when trying to explain and understand them. It is critical that fatlogs be broken down into smaller actionable backlogs before being given to an Agile development team or a large amount of time will be wasted.

Many times, I have found that the creator of the fatlog could have easily broken down the work it represents into several smaller backlogs that would be easier to explain and understand, even without knowing much about software development.

I often recommend to Agile development teams that they outright reject fatlogs and send them back up the chain.

“If you can’t take enough time to clearly state what you want, it must not be that important.”

This doesn’t excuse development teams either. Development teams should break down any backlogs they get into small tasks as well.

4. Not setting done criteria

What is the first thing a waiter asks you when you order a steak?

That’s right, they ask you how you would like it done.

If the chef doesn’t know what the done criteria is for your steak, the chef will have to decide what he or she thinks the done criteria is.

You may get back a well-done steak, or a rare steak, or something in between, depending on the personal preferences of the person cooking your meat.

This isn’t a good way to cook steaks and it isn’t a good way to cook software either.

In many software projects I often encounter lots of steaks being cooked but no one defining when they are done. The backlogs most often end up being “done” when time runs out.

It is very important to have explicit unambiguous done criteria for any backlogs being worked on by an Agile development team.

This means that the product owner should be defining some level of acceptance testing. It doesn’t matter if the tests are manual tests or fully automated tests (BATs), what matters is that some criteria is defined by which the team can evaluate whether they have achieved their goal or not.

Lacking this criteria is like a parent responding with “enough” when their child asks “how many more peas do I have to eat?”

Not having done criteria is demotivating and results in the finger pointing game of why the correct thing was not built.

I have found that if you tell someone exactly what is expected of them and what criteria they will be judged by, you get much better results than just throwing them in the ring, slapping them on the back, and saying “do a good job.”

5. Not letting the team be a team

Teams are strange organisms, especially Agile teams.

There are many dynamics that affect how teams act and interact. There are many ways to foster a healthy team and many ways to create unhealthy teams.

A healthy motivated team has synergy, a unhealthy gaunt team can be less effective than all of its members are on their own.

The key to having a healthy motivated team, is letting them be mostly autonomous. Regardless of your political persuasion, you would probably agree that when a country invades another country and sets up an unelected government to oversee the people, there are going to be problems.

The same thing happens in Agile development.

I’m not saying teams shouldn’t have accountability. But if you want to run a software project in an Agile way, you have to let teams self organize and self manage to some degree.

When big brother is always watching and interfering, team dynamics become very different. Naturally, teams usually develop their own cadence, leadership and roles (this is called norms.) However, when outside forces directly interfere with how the team does things, and they don’t have the power to decide their own fate, team members begin to realize that they need to look out for themselves.

Additional agile development resources

I’ve found it to be pretty difficult to find good resources on these topics, but here are a few books I’ve found useful that address some of the issues I described above.

• Succeeding with Agile: Software Development Using Scrum - This book is focused on Scrum but it applies to many different kinds of Agile projects as well. Mike Cohn and I usually agree on most Agile subjects.
• Agile Retrospectives - I’ve found this book to be useful for getting good idea for team retrospectives that can really help to break down some barriers and help teams learn to resolve issues themselves.
• Scrumban and Kanban and Scrum - Both of these books have excellent information about combining Scrum and Kanban and have great solutions for dealing with some of the problems I described above.

What do you think? Have I missed any of the major Agile project killers? Any useful tips for dealing with them?

Let me know in the comments below.

Follow @jsonmez

The post 5 Things That Will Make Your Agile Development Project FAIL appeared first on Simple Programmer.

I’m very excited to announce a brand new podcast Iris Classon and I have put together called “Get Up And Code!”

I’ve always wanted to do a podcast, but I’ve been looking for the right topic and right co-host and I believe I have finally found both.

Get Up And Code!

Podcast website: http://getupandcode.com

iTunes link: https://itunes.apple.com/us/podcast/get-up-and-code!/id646958161

Even though I spend a lot of time talking about code and programming, fitness and nutrition are a big part of my life.

I’ve been lifting weights and running for about 18 years.  Over the course of that time, I have learned quite a bit about gaining muscle, losing weight, running and many other topics—mainly from my own mistakes in those areas.

Iris Classon, my co-host, is clinical dietitian and international personal trainer who also does bodybuilding (on the fitness scale), ultra running and extreme sports.  But, if you are reading my blog, you probably know her as that pink haired coder and Telerik evangelist.

We decided that our shared love for all things code and all things fitness is probably also an overlap that many other programmers and IT professionals have as well.

So, we decided to do something that hasn’t been done before—create a fitness and nutrition podcast targeted at the IT industry.

An experiment

Neither of us hosted a podcast before, although we’ve both been on Hanselminutes and I’ve been on The Tablet Show a couple of times.

This will be a bit of an experiment and things might be a bit rocky at first, but I am sure we’ll find our way.

If you’d like to support us in our efforts, please spread the news, follow @GetUpAndCode on twitter and like our Facebook page!

Follow @jsonmez

The post Introducing The Get Up And Code Podcast! appeared first on Simple Programmer.

JavaScript is a bubble.

Just like the housing bubble.

Just like the .COM bubble.

And just like any bubble, the JavaScript bubble is bound to pop.

Sure, JavaScript is everywhere.  It appears to be growing at a rapid pace.  But I’m willing to bet that we are getting close to a complete reversal that will throw JavaScript down from its throne, shattering its JQuery scepter with it.

JavaScript never really made a comeback

Part of the problem with JavaScript is that it’s propped up on the back of another technology. See, JavaScript itself was rejected long ago. If JavaScript was a wonderful language to develop in, its wonders would have been praised years ago when it was first introduced. But I remember cursing JavaScript 15 years or so ago.  And I wasn’t alone.

Yes, I know it was a dark time, but recall, if you will, your pure hatred for JavaScript.  You know, before it was so cool.

Then how did this ugly wart of a language become so popular?

Well, you see, it was this little library called JQuery. JQuery solved a very real and annoying set of problems that wasn’t around when JavaScript was first invented: manipulating the DOM and making Ajax calls.

JQuery was basically designed to make JavaScript possible to work with. Before JQuery, DOM manipulation and Ajax calls were difficult. After JQuery, they were easy.

So JQuery ended up being this big band-aid that covered up all the ugly JavaScript code you didn’t want to write and made doing what you wanted to do much easier.

You may disagree with me on this point, and you are welcome to do so, but even if JQuery isn’t the reason JavaScript is so hot right now, do you honestly think JavaScript would have become so popular if JQuery never existed?

The problem with JavaScript

I want to love JavaScript. I really do.

I know it doesn’t sound like I do, but just like I can’t make myself like sweet potatoes—even though I know how good they are for me—I can’t like JavaScript.

I’ve tried many things. I’ve put some butter and brown sugar on a freshly baked sweet potato. I’ve doused it with hot sauce. I’ve even pretended it was a regular potato and dressed it up like one. But, the fact remains, I just don’t like sweet potatoes. It’s something in their very nature that I despise.

I’ve tried the same thing with JavaScript. I’ve added libraries that make it much sweeter, like JQuery and Backbone.js. I’ve used tools like CoffeeScript and TypeScript to try and pretend it was a more palatable language. But the fact remains, JavaScript has some things that are fundamentally wrong with it that no amount of covering up or pretending will fix.

If JavaScript wasn’t so ugly at heart, then a book called “JavaScript, The Good Parts,” probably wouldn’t be the #1 best-selling book on Amazon for JavaScript, the #3 best-selling book on web development, and the #4 best-selling book on software development, would it? (Go ahead and check it out for yourself if you don’t believe me.)

I don’t really need to tell you again what is wrong with JavaScript. If you use JavaScript, you know. If you don’t use JavaScript, just search for “why JavaScript sucks” on Google and you’ll get plenty of answers.

The point is, unless we are going to be completely disillusioned about it, we can probably all agree that JavaScript is not the greatest programming language that was ever created, and that it has some glaring weaknesses.

My point is not to bash JavaScript

Before you pitchfork me, I want to clear a few things up.

I don’t hate JavaScript.

I don’t suggest you shun JavaScript and go off with me to a floating island in international waters where we will build a new internet, one that isn’t infected by JavaScript.

I actually use JavaScript.
Not only do I use JavaScript, but I have to use JavaScript and so do you.

And if you are smart and want to have a good career in software development, you’ll take everything I am saying with a grain of salt, knowing that I could be completely wrong.

If you are smart, you won’t just dump JavaScript out the window, betting that it will fail, because it might not. It might grow to become the one universal language that replaces all other programming languages. JSON sempiternus!

But, on the other hand, if you are smart, you won’t put all your eggs in the JavaScript basket either. Even though the world seems bright and cheery for JavaScript developers today, it also seemed equally bright and cheery for Blackberry devs not too long ago. And look how that turned out.

And if you are solely a JavaScript developer or you really like JavaScript, I sincerely don’t mean to offend you, but I offer this piece of advice: You are not the technology you happen to be using.

Trust me, if you’re a good developer, you’ll still be a good developer even if JavaScript goes away.

What is actually awesome about JavaScript has nothing to do with JavaScript

No one gets up in the morning and says, I want to have bamboo shoots shoved under my fingernails. (Ok, well maybe some people do, but those guys are still writing object-oriented Perl.)

Yet, at the same time so many developers get up in the morning, fire up their IDE—or excuse me, lightweight text editor which has 50 plugins installed to give the capabilities of an IDE, but is not an IDE—and write JavaScript code. Why do they do it, unless they think JavaScript really is awesome?

It’s because all the stuff around JavaScript and built with JavaScript and on top of JavaScript is actually pretty awesome.

As much as I loathe JavaScript itself, frameworks like JQuery, Durandel, Backbone, Angular, Knockout and more are pretty darn cool.

Not only that, but JavaScript is everywhere!

Every browser is a JavaScript interpreter. Every notebook, PC, tablet, and smartphone can run JavaScript.

There are even cool server technologies, like Node.js that are built with JavaScript.

JavaScript runs in the browser, it has plenty of hooks in it for manipulating the DOM, and it has tons of cool libraries that give you the power to do awesome things, what’s not to love?

This is the part where I tell you what is not to love

What’s not to love, is that all of that stuff has nothing to do with JavaScript itself.

Take JavaScript away and replace it with another programming language and you don’t really miss anything.

Ever seen a movie star without her makeup? Makes you realize that any halfway decent looking woman could be a movie star, with the proper styling.

The same goes for JavaScript. It is a language that has been dressed up to look like something it is not. What we all love about JavaScript is not the language itself, but all that makeup that has been caked on, a little bit of mysterious seduction it infers, and the stylish clothes it wears.

But, what is starting to happen already, and what I believe will continue to happen, is that people will start to get sick of that caked-on makeup look and high maintenance personality of JavaScript.

All those frameworks were really useful at first, but they are becoming such a huge mental burden. Are you worried about what JavaScript framework you need to master and keeping up with what is the hot one to use on any given day? I am.

You can only build so much on top of something else, before you have to wipe the slate clean and start over.

I don’t know when this will happen with JavaScript, but I am pretty sure it will happen.

It is very likely that a language like Dart, that can do everything JavaScript can do and more, will likely someday dethrone our web development king.

JSON sempiternus!

By the way, check out my new experiment on YouTube, going to release a short video each week.  Let me know what you think.

Follow @jsonmez

The post Why JavaScript Is Doomed appeared first on Simple Programmer.

What do you do when you make a mistake?

Not just in your job, but in life in general?

I’ve made some pretty big mistakes in my career

.

Just last month I was giving a talk at the Orlando Code Camp and I forgot to bring an adapter to go from DVI to VGA for my MacBook.

That was a huge mistake!  I spent most of the presentation trying to get someone else’s laptop to work with my setup.  Finally, in the last 5 minutes I managed to actually get my demo started.  (Luckily the talk was about how to create a web service using Service Stack in 5 minutes.)

I’ve made huge career mistakes, like quitting a job with a certain company that got sold a year or two later, which would have resulted in a pretty big payday for me.

I’ve made dumb coding mistakes that have caused bugs to go into production and resulted in some embarrassing moments for myself.

I could take up this whole post just listing all the mistakes I have made.

The point is…

Everybody makes mistakes

It doesn’t matter who you are or how good you are at development or whatever else you are doing, you’ve made mistakes in the past and at some point in the future you’ll make them again.

The fact of the matter is that mistakes are just part of life.

We can try to avoid them.  We can try to deny them.  But, regardless of what we do, mistakes will happen, so it’s best to learn how to deal with them.

Own up to it

The most important thing to do when making a mistake is to own up to that mistake.

Chances are everyone else already knows that you made the mistake, and no amount of excuses or finger pointing will change anyone’s opinion of it.  Trying to avoid the ownership of a mistake is more likely to make you look even worse and damage your credibility.

Sometimes the mistakes truly are only visible to you.  In those cases it can be even more difficult to own up to the mistakes.

I have a tendency to try and pretend like somehow the mistake I made was not a mistake at all, but rather the wisest choice I could make given the set of circumstances I faced, regardless of how bad the outcome was.

This is called justification.  Not only is it not healthy, but it is a complete waste of time and energy.  When you justify your mistakes instead of acknowledging them, you completely void any possible benefit you may have gotten from making that mistake.

Justifying mistakes is tantamount to throwing your hands up in the air and saying “what comes, comes.”  It is taking away your power and control over your life and career and giving it to everyone else.  It is becoming a victim of your circumstances instead of a master of your destiny.

Long story short, when this !@#$ hits the fan in your life, it’s probably your fault, so own up to it.

Fix it (if possible)

You can’t always fix your mistakes.

Once I deleted my backup folder and emptied the recycle bin, BEFORE I had copied that folder to my new backup drive.

That was it, it was done.  There was no fixing it at that point.  Oops.

Fortunately though, in many cases mistakes are fixable if they can be identified and you are willing to own up to them.

There is a wise old Turkish saying that goes something like this:

“No matter how far you’ve gone down the wrong road, turn back.”

I always try to remember this saying, because the first tendency I seem to have when caught in a mistake is to try and ride it out with the foolish thought that I’ll save what I invested so far by continuing to go down the wrong road.  As if somehow the wrong road will magically become the right road.

If you have made a mistake and you know what that mistake is and that mistake is fixable—fix it!

Don’t try and “ride it out” or build on top of it.  Tear down the building to the foundation and fix the mistake, before it can get any worse.

Little mistakes become big mistakes when we let them fester.  Big mistakes become tragically life altering mistakes when we ignore them.

Guard against future mistakes of the same kind

Now, like I said before, we can’t always fix all of our mistakes, (although you’d be surprised how many mistakes you can actually fix if you are willing to eat a little humble pie,) but we can guard against future mistakes.

The first thing that I try to do after I have made a mistake that I have identified, owned up to and have tried to fix, is to figure out why the mistake happened and how I can prevent it from happening again.

Far too many people make the same mistakes over and over again, because they don’t take careful steps to prevent the mistake from happening again.

It is very easy to move on from a mistake or dwell on the mistake without making any effort to analyze why the mistake happened in the first place and how it could be prevented in the future.

Many times in a rush to move on to the next thing, I’ve been guilty of this meta-mistake myself.

It is very important to examine a mistake with a clear head and honestly evaluate what brought about the mistake and why exactly it was a mistake.

Once you know what caused the mistake, it is important to put in place a procedure or some other sort of guard that will ensure that mistake doesn’t happen again.

In code, I’ll often add a new unit test or some other type of automated test to ensure that a bug I fixed can never happen again.

In life, I often don’t find it that easy.  Many times the mistakes and the consequences of those mistakes are quite far apart, so it can require a very careful and honest analysis to determine the connection and find a future remedy.

I have a high tolerance for people making mistakes, because I know we all make mistakes.  But, my tolerance wanes for people who continually make the same mistakes again and again.

Single mistakes are expected and accepted, repeated mistakes indicate incompetence and carelessness.

Move on… quickly

It is to easy to get hung up on a mistake and become paralyzed by it in such a way that it prevents you from having future success.

I seem to have an instinctual desire to throw away what I am doing or try to completely wipe the board clean, whenever I make a mistake.

I remember as a child playing Nintendo and hitting the reset button over and over again every time I died on a level or messed up in the slightest, instead of continuing on and doing my best from that point forward.

I’ve embarked on projects and ventures where I have made mistakes and instead of plowing forward to learn from them, have simply given up.

Giving up isn’t the same as moving on.

Sometimes it’s the same and you need to know when changing directions is the right course of action, but often we are so caught up in our mistakes that the continual focus on those mistakes shifts focus from what we should be working on and derails us completely from our track.

I’ve learned that is it important to quickly acknowledge the mistake, take corrective action, guard against it in the future and then move on.

This means letting go of it and accepting mistakes as the only way to move forward.

Fail, but when you do, just be sure you are leaning in the direction of success. Then when you fall it will be forward.

I’ve had many situations in my career where I know I’ve screwed up and I know what I did wrong, but the process and consequences of my mistake have drained the enthusiasm and spirit out of me to press on.

In those situations I’ve had to tell myself that I was not going to give up and I was going to make the best of my current situation, regardless of what it is, instead of making the worst of it.

What about you?  What kinds of mistakes have you made and how did you recover from them?

Follow @jsonmez

The post How To Deal With Making Mistakes appeared first on Simple Programmer.

Personal privacy is over.

The world knows more about you than you do and soon it will know even more.

We can keep fighting the battle to secure our privacy or we can learn how we need to live in the coming age where all of our actions are potentially in public view.

Before you get worried that I am going all political on you, don’t worry, I’m not condoning the invasion of personal privacy or the eradication of it, but at the same time I’m not supporting it either.

I’m simply looking at the patterns that are emerging as the technology of our society increases, making this transformation inevitable.

I’m actually staunchly opposed to expressing my political thoughts publicly from any forum, even from my own blog, and I often recommend others do the same, mostly because of this transformation that is taking place.  I’ll talk more about that a little later on, but first let me tell you why privacy is indeed dead or at the very least dying.

It’s more than Google Glass

Google Glass itself may not change the concept of personal privacy, but wearable computing is certainly the future.

Google Glass

What Google Glass does do, is sets up the stage for wearable computing to go mainstream.

I hear many people complaining about Google Glass saying that they would never wear the technology in public, because they would look like a geek or a dork.

But, this is exactly what makes innovations like Glass so important.  The first thing that changes in society is perceptions.

Google Glass may not have the momentum to bash through the barrier of the “dorkiness” of wearing a computer on your head, but it will make a dent in that wall and over time that wall will come crashing down.

When everyone is wearing cameras it will be impossible to control them

We’ve already been through this before.

We’ve been through it at least two times that I can think of.

First, there was the USB drive.

All of a sudden we could plug a small device into just about any computer and pull data off of it or put data on it.

Computers without disk drives or network access were no longer inaccessible.

The data on them was no longer securable.

Sure, many companies tried to make it so PCs in their buildings were secured, but most companies realized that they would just have to deal with this new reality.  You had to realized that if a person had access to data on a computer, they could take that data home if they wanted to.

The same type of thing happened when all cell phones started getting quality cameras on them.

Secure facilities tried to prevent people from taking pictures by disallowing employees to bring in cell phones that had cameras, but that didn’t last long.

It became apparent pretty quickly that it would be just about impossible to prevent human beings who now were part human, part iOS or Android, from bringing their cell phone into a building.  And, even if you could, someone who really wanted to take a picture would find another way.  The technology that brought tiny cameras to the backs of every cell phone also pioneered the mass creation of tiny cameras that could easily be hidden anywhere.

Already governments and family matters have been thrust into public view

We currently live in a society where it is just about impossible for public figures or government to do an action in public and try to keep it secret.

Think about all the times in the last few years when a police officer stepped over the line or a government tried to quell a public protest by using violence or excessive force.

Each and every time, not only was there photographs and videos of the incidents, but the information spread to the entire world almost instantly through mediums like Twitter and Facebook.

The fact of the matter is, it is almost impossible to hide or cover up anything that occurs in public view.

Consider the amazing and tragic events that recently occurred at the Boston Marathon.  In a huge crown of people, it only took about a day to identify two suspects out of the thousands of people in the crowd using images and video provided by the public.

This event was significant, because it showed that even when people aren’t trying to capture data about you in public, they are capturing data.

You don’t have to worry about the government tracking you. The government doesn’t have the power or capability to do it.  Instead, you are tracking yourself, you are tracking the government.

Oh, and if you still think family matters are private, you probably haven’t heard of this thing called Facebook.

Don’t think you can get a divorce, or even get into a heated argument with your teenager and not have it become public knowledge on Facebook.

The problem is that there are too many leaks now to private family matters and it is too easy for those leaks to spread the information.

Worse yet, those naked pictures you took of yourself, or unfortunately your less worldly-wise teenager took of themselves, that you thought no one would see… all I can say is “good luck with that.”

The reality is the trend against privacy will not reverse

Not only are you willingly providing your own private information, but companies are actively mining it.

From tracking cookies, to search histories, to friends graphs, advertising link clicks, foursquare check-ins, what you post on Twitter and more, everything is being recorded and tracked.

Each piece of information by itself is not very valuable, but when you combine all this information together, a very real and precise silhouette begins to emerge from that frosted glass window you are hiding behind.

And, like I said before, even if Google Glass is not successful, it will not be long before every human walking around in public and in private wearing a camera that not only you can’t control, but likely you won’t even be able to see.

Not only will we all eventually be wearing cameras, but the data from those cameras will be instantly uploaded to the cloud, where it will become a permanent record.

There are several unstoppable factors that will continue to improve over time, which will fuel this trend:

• Miniaturization of technology
• Increase in efficiency of batteries
• Increase in processing power
• Prevalence of social networks

As technology gets smaller and is able to be more mobile, and the ability to crunch big data and distribute data through social networks increases, privacy will greatly diminish.

The reality is we are transitioning from a society where private is default and public is a choice, to one where public is default and making things private requires considerable effort and in some cases is impossible.

How to live in this new “public by default” world

Rather than uselessly spending our energies trying to fight the trend of the world, it is better to spend those energies tempering our behavior to fit the world we are living in and will soon be born into.

It starts with getting in the habit of assuming everything we put on the internet will not only be made public, but will likely be a permanent record that is easily searchable.

Many times throughout the day I watch my Twitter or Facebook feed fly by and I cringe at all the people who are posting their own private opinions that should not be made public.

I’m not saying you can’t have an opinion, but I am saying that you have to be wary that the opinions you express will become visible by more than just the people you share them with and will become a permanent record which you cannot be alienated from.

Are you a republican?  Are you a democrat?  Perhaps you are a libertarian or a communist?  Do you support gun control?  Are you pro-choice?

Good!  Stand for something, but there isn’t much of a need to say it out loud.  Let your actions stand for you, they are more powerful than words anyway.

The problem with tweeting about your political views is that they may change.  You might be leaning one political direction today, but 5 years from now, you have changed your mind completely.  But, guess what won’t ever change?  That’s right, the permanent record of what you said on the internet.  If you ever decide to run for office or even go on a date, those words you said may come back to haunt you.

And even if your mind doesn’t change, do you really want to decisively set half of the world population directly against you?  I can’t image many scenarios where this is a good idea.  Even in politics, bipartisan political figures are usually much more successful.  (Ok, I made that up, but I think it’s true.)

I’m getting a little bit away from the point, but what I am trying to say is that you need to strongly consider things before you put them on the internet, because what you say online is public and permanent.

It goes beyond just the internet of course, even though it may start there.

We have to prepare ourselves for a world in which the moment we step out our door our actions are recorded.

In this kind of world, we have to be careful not to try to hide things that are likely to be destructive to us if revealed, because we know that what is hidden is likely to be revealed.

It means being more upfront and honest in our dealings and being careful to manage our image to make the focus be on the images and presentation that we desire while diminishing the focus on the image we do not desire.

When you don’t have control over the information itself, you have to instead focus on controlling how that information is presented.

It all comes down to living in such a way that clearly reflects the values you are trying to represent and knowing that perception is 100 times more important than reality.

There is no time like the present

If you are still living like you can hide your tracks and like your track record doesn’t matter, you’d better stop now, before it’s too late!

The answer isn’t to try to find better hiding places for your secrets and to try to wall yourself away from the world, but instead of accept the reality of the situation and find the best way to adapt to it.

“Man is not what he thinks he is, he is what he hides.”
― André Malraux

If you like this post don’t forget to Follow @jsonmez or subscribe to my RSS feed.

Follow @jsonmez

The post Privacy Is Dead, Time To Prepare For The Future appeared first on Simple Programmer.