Installing & Using Chocolatey Package Manager for Windows

I'm very used to using tools like npm to install node modules in an OS X bash environment.  Or tools like Homebrew + Cask as well, I use both ways.

Windows sorta has a Homebrew'ish like that called Chocolatey which is a Nuget based package manager via command-line that attempts to mimic something like the popular Homebrew in OS X.

With package managers you can do all sorts of cool things such as install stuff in 2 seconds rather than go out to the net for executables.  For example one can do this to install a bunch of common programs you might use in your development environment:

choco install google-chrome-x64

choco install firefox

choco install git.install

choco install atom

choco install 7zip

choco install ccleaner

choco install node.js

choco install filezilla

choco install fiddler

choco install virtualbox

choco install pdfcreator

choco install windirstat

choco install itunes

and because you're using a package manager and its commands, that means you can automate creating your development environment too by creating a chocolately script or HomeBrew script or whatever.  

Imagine creating a script that you could run on a fresh install of windows that does a bunch of chocolatey commands (or equiv of Homebrew in OS X) to install and setup your entire local dev environment.  Sure would save a hell of a lot of time.  Especially if you haven't imaged your laptop the last time you went through the pain of setting up our dev environment manually.  When i say manually, meaning do the typical go to the web, go to FireFox, Google, and other sites to manually click all over and download and then run the exe, stupid wizards, all that.  You can bypass a lot of that hassle and save time by creating scripts along with using Chocolatey or HomeBrew and automate most of the things you use as a developer.

I use Powershell for all that I do.  So I'll use PowerShell to install Chocolatey.  You can also just use the command prompt but why not just use PowerShell is my argument.

Here is how to install it

    There are a couple little pain points that you need to be aware of if you haven't used PowerShell and such while trying to install Chocolatey that you'll come across.

1. First, make sure you elevate privileges with PowerShell to allow the Chocolately script to be run on your comptuer

  Run the command Set-ExecutionPolicy RemoteSigned

    2.  Install Chocolatey
         Run the command: 
           ex ((new-objec net.webclient).DownloadString('https://chocolatey.org/install.ps1'))

3.   Start using it

      Here I'm installing Git for Windows with a simple Chocolatey command:

So simple.  Now it's installed.  Note that there are many Git packages up on the Chocolatey website.  This one installs Git and then you can start making Git commands right from PowerShell thereafter:

This is not installing something like Mysis Git Bash prompt.  If you want something like MysisGit, if there isn't a package that does that for you in the Chocolatey Packages directory listing then you'd have to go manually install it yourself.

You can also quickly install stuff like Chrome which will do everything you expect..pulls down the Chrome executable runs it and installs it for you without you needing to do a thing.  All you have to do is type choco install google-chrome-x64

This just scratches the surface.  Windows 10 is coming out with their own built-in Package Manager finally.  We'll see if it's any good.

Setting up VideoJS with Intrinsic Ratios

I use VideoJS for DimeCasts.net.  It's been a proven HTML5 player that is used by Google, funnyOrDie.com, and many other well known websites.

I realized for some reason that VideoJS was not being responsive on DimeCasts.net lately.  What I mean is if you make your browser larger or smaller, the video player should re-sample its size to fit that new browser size and still maintain an aspect ratio that fits into the container in which the video player sits.

I'm almost finished doing a re-code of the views using bootstrap.  Originally DimeCasts.net which was started in 2008 was designed via rigid table driven layout.  I'm finally getting rid of this after taking over DimeCasts last year.

However even when I have the viewsre-coded and using Bootstrap, I found that VideoJS still wasn't re-sizing on browser size changes.  

A quick search brought me to this post.  

So all I did to get it intrinsic is to then just add that padding to the containing dive around the video component and the video player is now responsive (changes dimensions to fit the container) when you enlarge or decrease your browser window.

I also changed the width and height of VideoJS to 100%, and surrounded everything with a paragraph tag.

For example:

.makeVideoIntrinsic
{
        padding-bottom: 20%;
height: 0px;
}
            <p>
                <div class="media-body makeVideoIntrinsic">
                        <video id="<%=ViewData.Model.EpisodeName%>" class="video-js vjs-default-skin"
                            controls preload="auto" width="100%" height="100%"
                            poster="../../images/CastThumb_Large.png"
                            data-setup='{"autoplay": false, "preload": "auto"}'>
                            <source src=<% = ViewData.Model.FileName %> type='video/mp4' />
                        </video> 
                </div>
            <p>

I'm happy to say that the new Bootstrapped DimeCasts.net update will be out soon.

Do You Need Cucumber or even BDD?

Do You Need BDD or Cucumber?

This is a debate that has been ongoing for a while in the development world.   

The crux of the arguments out there are have been:

• "BDD is a lot of overhead", meaning writing the tests slows us down
• "You don't need BDD, it's a waste of time"
• "Business people don't care about technical Parts of BDD or writing the tests" so "They never write them so BDD is pointless"

I'm sure you've read or heard those arguments time and time again, I know I have.

I do not claim to be a master in BDD however I'm getting to the point to where I'm doing it enough to where I'm able to draw the lines and see those arguments start to shrink more and more.

Proof

You want Proof you say! Well you got it.

For this blog post I'm focused on a recent conversation I had with a close friend who is seasoned at BDD and TDD.  I passed him this argument by Kevin Liddle because I'm truly interested in working more with BDD daily, and want different opinions out there period.

He disagrees with some arguments out there against BDD as well as Cucumber.  Because in his organization it has only been a great tool and helps their organization and has seen much success with Cucumber.js.  He is running several large development teams right now in his organization (all of which are doing BDD and disciplined TDD) and has been promoted to drive his process down to and lead rest of the organization because it's worked so well for the company overall.

He has found success with BDD and specifically Cucumber.js in his organization all the way from the non-technical business stakeholders all the way down to acceptance of BDD from his own developers across all the teams he manages.

His organization isn't some start-up, it's big.  And things have to work well.  They're driving the next wave in fact and leading their industry in terms of the awesomeness coming out and competitors are taking notice and actually using their APIs as a result!  What more testamony to design, BDD, and TDD can one get.  This is real tangible stuff at a large organization with a lot of devs.  And if anything could put DHH's baseless argument against TDD to rest, this would be a great example.

The following is a summary of our interesting conversation and sheds some light on one good sized organization and their dev teams who have seen huge value in Gherkin, Cucumber, and BDD.

Remember the ".js" after Cucumber because it's significant as you will read further below.


"BDD is a Waste of Time!"

First, this is nonsense.

If you haven't seen the value yet, then most likely one of these reasons:

a) Have you tried to or are you actually coding BDD yet? 

If you've only read about it then then why make uninformed biased conclusions if you've never experienced it yourself right?

b) You've done some BDD but did it in an organization which has made a mess of it.  

Well then of course you might view it that way

c) Maybe your organization isn't going about it in a lean or clean way:

• Cutting out QA completely from the equation
• Maybe you're tests themselves are written poorly such as including implementation details in the Gherkin which should not be there.  BDD is for high level functional requirements, not the how to implement them
• You're still using older framework that make it hell to maintain those kinds of tests and running them are slow because of that framework

For me, BDD Makes Sense and is Valuable Without Question

I've been doing some Cucumber.js for my own personal projects lately and it just makes complete sense.  BDD tests are a perfect starting point from Agile Story to starting the actual related code for that story.   Watch this video from Corey Haines, he shows you nicely how to start a new project both from a Business Domain / Priority List perspective right down into starting your first BDD tests, and then implementing the code via TDD.

BDD tests guide you.  I honestly can't think of not doing them anymore after having done some in Cucumber.js.  Because they force you to think about the business requirement at the highest level first.  It's a better starting point than taking some garble that varies from Story to Story and assuming you're getting off to the right start with just diving into your TDD tests.  Everything is clear when based off Gherkin and verifiable.

BDD tests drive the lower-level implementation.  That is they determine the direction and scope of your TDD tests once you're ready to implement the real code.  BDD forces you to think about what scenarios you need to think about first, as lean as possible, and at a high level.  And then that reduces the scope of your unit tests making the correlation of TDD tests to BDD tests a tight nit family.

A Proven Process

First off if you are trying to BDD in your organization and you're expecting Stakeholders, PMs, or QA to write any amount of code is a ridiculous expectation that shouldn't be in your organization in the first place and you are going about BDD completely wrong.  And that goes for QA too!  They shouldn't be writing BDD...period.

Business Stakeholders could give a crap about code.  They care about getting requirements right and seeing those being built succesfully and with high quality form the development team.

My friend told me BDD has only helped.  In no way is it debated in his organization, because it's produced results.  Proof first-hand in a large organization.  Because they do it right.

Quotes from my friend from our discussion

"You have to keep things in perspective.  We're talking about it in the context of Cucumber.js with Node.js, not older Cucumber frameworks.  Cucumber.js and older Cucumber are not the same in terms of speed to code and run those tests.  So the speed argument doesn't apply to what we do here.

As for the argument that business people won't write Gherkin or that Gherkin is a waste of time isn't true for our case.  

That's because all our business people have agreed as a standard to write acceptance criteria in Gherkin format right into their Jira Stories and we don't ask them to do anything other than that, that's where it stops.  That's not difficult for them to do, and they like it!  We don't expect them to write any code.  In fact we don't even really have QA anymore, we've trimmed QA out of testing completely and have very few QA resources period.

Our Engineers then simply take and copy the scenarios that are in Gherkin format from those Jira stories that were written by the non-technical managers and PMs, and and write a BDD test for them and it's not a big deal to any of our developers.

And Since it's fast to write tests and setup Cucumber.js over Node.js, there's not a problem with it being slow to run or code at all...so this is not the same as using older Cucumber to do this and so it's not a problem for our business or devs and it works great for everyone here.

Our team has been doing it for a while and don't complain about it…they actually like doing it.   Where teams start bitching and stuff is a dirty little secret.  It's usually those teams who have QA staff.  And the QA staff is essentially doing half of their testing for them.  Once you remove the QA staff from the equation then it's different.  

You tell the engineers they're responsible for the quality…then all of a sudden that automation makes a lot more sense to those engineers.  So that's the piece you are not seeing in those arguments also…is that most of these engineers tend to have QA resources as part of your team and is why BDD is getting a bad rep.

We then run our versioned automated functional tests (Cucumber.js BDD test suites) every 30 minutes against all our environments all the way up to production on our apps all the time."

That's what Gherkin is For

Given I am a user
When I go to the main landing page
And I see that there are some events scheduled for Metallica

If you think about it, how many times are you in an iteration planning meeting and you're trying to write some of the acceptance criteria and your description and details around that varies greatly in who wrote it in terms of how it's written...it's usually a big mess with no structure.  In Story A someone wrote it in a nice clear concise manor.  Fine.  In Story B for the same product, same iteration wrote too much, or wrote it messy because they have a language barrier, or just don't give a damn or just are not very good at writing to begin with.  That happens, because we are all different, we're all human.

But when you have your business stakeholders write the criteria all in Gherkin right in your story it just make complete sense.  That's the whole value of Gherkin to begin with.  A template to write clear and concise functional requirements anyone can understand and think out in a consistent and very clear manor.  

So stop having different people use different templates (or no template! even worse) for writing the acceptance criteria in your user stories.  Just use Gherkin style.  It's just too easy and it makes too much sense not to.  Be consistent.  Be clear.


Developers Take Gherkin and Write The BDD Tests Themselves, not QA

Yes I said Developers...not QA, nobody else.

No this is not far fetched and no this doesn't slow down the team.

Your developers (not QA!) simply and literally copy that Gherkin typed by your business owners from the stories and when they start on implementing a story, first they they do is create the Cucumber.js BDD tests starting with the Gherkin themselves and don't even question or complain about doing so because it just works.  

You start with the Gherkin written in whatever Agile Software you're using to create Stories, have the business people write that gerkin as acceptance criteria in the stories, then have engineers take that Gherkin and write the BDD tests.  After you have your BDD tests written, they serve as a guide in the next step which is to start writing the TDD to implement the real code for those BDD scenarios.  It's very much a controlled, clean, and fast way to get things done.  It's a lean way of coding and getting shit done.  

There's no going to QA or having an expectation for anyone but the developers to start implementing the rest that's under that BDD.

Cutting QA Out, Are you Joking?  You Jerk!

This is not a new concept.

It's not theory or wishful thinking for some organizations.  It's actually really being done more and more across organizations today as they embrace more Pair Programming coupled with TDD and figure out how to make BDD work.

When BDD is working right and is working for non-technical owners, that's where things start to change.

It's because some organizations utilizing BDD have gotten to a certain point to where their BDD process is driving things and working for all involved and that when oupled with TDD and simple design, everyone starts to see a very low bug count and even rare corner cases aren't there much anymore on all apps being developed or new features added or changed.  So you end up literally not needing to have that extra layer of a QA department bogging you down.  It's straight up business owners to devs.  The Business owners know what needs to be done to meet a requirement for the business and it's getting done by the developers effectively.

Developers code the BDD for the Gherkin, and develop the code via TDD.  There's really not much more to do and really not much need for much if any QA after that when everything is aligning this well in an organization.

Obviously Can Also Use Other Frameworks

I'm not completely biased toward Cucumber although my wordage might indicate that in this post.

Note that there are other test frameworks such as Mocha.js where you can kinda do the BDD and TDD all in one roof.  Currently I'm trying to use Mocha.js for the TDD tests and Cucumber for the BDD on my projects.

But I'd still see some value in using Gherkin-like wording in Agile Story acceptance criteria.  And then implementing the code for that by devs.  You could use other frameworks outside Cucumber is my point.  It's just that by adding the Gherkin-like wording is still valuable, clear, and maintainable at the story level when written in your Agile Stories during iteration planning.

Conclusion

I think the most important points coming out of our conversation were the following:

1)  Just have your stakeholders or PMs write the Gherkin syntax in the Agile Stories as the Acceptance Criteria, no coding required

2) Devs should be picking up the Gherkin from those stories and writing the BDD tests themselves, not QA

3) It's been proven to be a very Lean way of producing code and satisfying business requirements

4) Cucumber.js and Node.js changes the ballgame on the old argument of Cucumber is slow or time consuming for devs

5) The teams who have QA doing the BDD tests are actually putting up a wall to getting the actual work done and tested

6) QA is being removed from the equation more and more entirely, because bugs are low when BDD and TDD work well and you have clean, testable, and maintainable code as a result of that and keeping things simple / minimal / lean


Be Careful

So be careful of the general arguments out there against BDD in terms of if you need it or not.  And in my particular conversation, revolving around Cucumber.

Things are changing in both the BDD framework scene these days, and how BDD is being done.

Arguments that have existed against BDD and against Cucumber in this case are becoming stale and no longer true in some organizations.

Setting Up WebStorm for io.js

I use JetBrains WebStorm as the main IDE for coding JavaScript.  I'm using it currently for coding with io.js, which is the new port off Node.js and I'm using this IDE to work with other libraries like express.js, mocha.js, and so on.

Initially I was in the editor trying to setup my project for a website recode and was coding some express.js code to get a web server and page up and running and noticed that JSHint and JSLint had trouble recognizing io.js (Node) and express.js in terms of JSHint and JSLint intellisense.

I found out there's a fair amount of configuring in WebStorm preferences that you need to be aware of and set for io.js, adding libraries like express.js, and so on. 

This will give a good list of what to do in general to get everything set right and intellisense working right for node.js, io.js, and any extra libraries you're tacking on (such as express.js, etc.).

Here's What I Saw initially

Initially before I started to have to fiddle with WebStorm preferences, this was the state of everything.  I had created a new project and initial boilerplate files and some initial code in express.js.

Notice JSHint and JSLint's intellisense has no clue what this node and express.js code is.

Preferences | Language & Frameworks | Javascript | Libraries

Preferences | Language & Frameworks | Node.js and npm

Here's What To Do

Ensure that you have a root package.json File With Correct Dependencies Defined

In the command prompt (bash), cd to the root project folder then type npm init
This will take you through a wizard to quickly and easily create your initial package.json file
Now you should have a root package.json meaning it's sitting in the root project folder
(My root folder is Website)

Ensure Your App's JS file is Inside Your node_modules Folder

Make sure your app.js (mine is called dimecasts.js) file is inside your node_modules folder that sits in the root of your project's parent folder

Preferences | Languages & Frameworks | JavaScript | Code Quality Tools

Make sure JSLint and JSHint validation are enabled; those should always be enabled period in WebStorm no matter what you're working on.  The point here was also to make sure that intellisense for both these tools could recognize Node and Express.js syntax..which was not working originally since we had to change some config settings as we're about to do below for Node and express.

Preferences | Editor | Inspections | JavaScript | Code Quality Tools
Enable JSHint and JSLint here also

Preferences | Plugins
This should have already been enabled by default when you installed WebStorm but double check that Node is enabled

Preferences | Languages & Frameworks | Node.js and npm

Change the path for Node interpreter to iojs

Now go to https://iojs.org/dist/ and download the source tar.gz file for whatever version you have for io.js.  Mine was 1.3.0 when I installed io.js.

Download the file to a local folder; I copied mine to /usr/local/bin/..Click Then configure and browse to that file.  Mine was iojs-v1.3.0.tar.gz

Now it should be all set after clicking Configure:

Preferences | Languages & Frameworks | JavaScript | Libraries

Now you should see an entry for Node.js Core Modules for the source you just configured in the previous step. 
You may need to close and re-open Webstorm to see this or 

File | Invalidate Caches / Restart

One you are able to see it, enable it.

Preferences | Languages & Frameworks | JavaScript | Libraries

Double click on the Node.js Core Modules item you just enabled and it'll open an Edit Library window.

Set it to Project Visibility

Be sure to also check the box for "Node.js Globals".

Now we need to add express.js library in here so that intellisense picks up syntax for this library.

Cilck the Add button and attach a file.  

Browse to where your express.js file is under your project directory.  Mine was here:

File | Invalidate Caches / Restart

For the settings to start to be applied, you need to invalidate the cache and restart WebStorm.

Then once I opened up my express code, all was happy, and I'm getting Intellisense for node.

TDD - Don't Worry About Code Coverage In The Beginning

I came across a Quora question today on TDD and amount of Test Coverage to aim for. 

Here was my response.  But before I dive into that, let me state that TDD is an ongoing continual process of learning.  There are critical things you just can't skip, or things you have to become aware of and over time learn how to "do it right" and there are indeed right and wrong ways to go about it.  It's always a continual learning process as well, even for seasoned TDDer's.

1) People new to TDD or misunderstand it may be missing of the point of TDD Altogether

It's not only about tests and test coverage percentage.  

Sure you get coverage and confidence but it's even more about how TDD guides you and helps you to see things in code that you would not be seeing if you were to test after new code.  What you should be focused on is learning how to TDD, and striving to create clean, simple, maintainable code before you even think about % of test coverage you've got.

Also, there are a lot of teams out there who default to the conclusion that TDD == Just Unit Testing.  As a result, they immediately then conclude why should we even do TDD? We just do tests after, same thing, same effect...and after all we're "doing what works for us" so skat...

The "do what works for us" is fine and I believe a team should do that, but it's often used as a cop-out and reason not to try or learn and adopt TDD or in some cases doing to TDD what people have done to Agile which is to skip the goals and principles thereof.  That a team thinks they are doing TDD but some on the team think it's ok to skip one or more of the 3 laws of TDD (e.g. we can just skip the refactoring step because we can do that later because someone is breathing down our neck to get this feature out).  

And that's where the misunderstandings and assumptions start.  "Oh we have code coverage and we don't even need TDD! ", the party has started.  Or "TDD is the same thing, it's just adding code coverage, so we just add all the tests after".

I'm sorry to tell you but you missed the point of TDD and you don't understand it quite yet.

Such as:

• helps you to produce leaner code because it forces you to strive for simplicity and forces you to be more simplistic during the creation of tests and production code as well as the refactoring step which forces you to go back and make things even more simplistic (means you are not skipping the refactoring step as well)
• keeps you much more close to your code at all times in that it keeps you more aware and critical of your code at a micro level when you practice TDD

• It's about verifying if your tests are valuable during each step of the way because you're getting that feedback early and getting it right after you get your test to go green

The level of feedback and guidance when you code via TDD is way different in my experience.  You're much more critical of your code when you go very small steps with TDD and adhere to the 3 principals.  The 3 are a tight loop that works wonders...and you do not skip one or more of the 3.  Only until you do it, will you understand how powerful TDD is and how much it's really making you more efficient as well as your team once you get used to it and know how to do it right.

2) High Code Coverage Doesn't Automatically Translate to Value

Why?  What if your tests suck?  Just because you have code coverage doesn't mean your tests are good ones, or the right ones. 

In fact you could have wasted time adding all the tests after that were not valuable in the first place whereas you would have saved time if you had Test Driven your code in the first place and end up with more tests that are valuable.

Now TDD helps with that, it helps because along the way when you're doing test first and driving the code, your tests are more likely to be focused, smaller because you force yourself to stop once they go green, and find out immediately if they are valuable in that they give you feedback you can trust because you're also running those tests very often throughout the coding of a feature.  

But even with TDD you can add tests that are a waste, tests you can't trust, tests that are doing way too much or testing the wrong modules of a system that don't need to be tested, and the list goes on...it's a matter of practice and experience and making sure you run the test suite continually as you code more and more production code.  It's just that TDD helps you to have less of those useless tests because if you are following the 3 laws, and adding tests as you go,  in my experience it's likely you'll have less of those invaluable tests vs. valuable.  Value means you are getting immediate feedback you can trust and the feedback is based on micro

3) You have to be careful with Wonderful Metrics

Extending point #2, Metrics are wonderful tools to gauge what's going on but when being reviewed and gauged in the wrong hands, they can also push for the wrong goals in the beginning, miss the point,  or push for stuff that's not providing true value for the business.  

Example:  At a previous job, all the team cared about for the majority of the time was meeting numbers for Goals and Objectives, referring to the code coverage for the team as a whole.  And didn't want TDD...they  figured it's a waste of time because "oh we know what TDD is already".  And most on the team were completely happy with always promoting and tacking on tests after finishing new production code.  

There was no real push for the team to learn TDD so that the team could go through it's motions correctly and see its true value.    Some even bluntly refused to do / work hard at learning how to do any unit testing period regardless of trying to get a team to adopt TDD...so the overall base code coverage was minimal in the first place since half the team refused to unit test, the code coverage might have been 80% as only a couple on the team decided they were worth while, so really that goal in the end only covered 20% of the overall code being produce on the team...and we still didn't know what % of the code truly gave us value.  We knew that tests were helping but we did not now what code coverage was a waste and what code coverage were not valuable or trustworthy.

You may see bug count go down but what % of your code coverage is or is not contributing (not useful/trustful) to that the lower bug count, and what % of missing code coverage are we missing which could make that bug count go down further.  There's way more to read into testing and especially when you go the Test Driven route.

4) You can over test

Again this comes with experience in terms of recognizing when you are doing so..testing things that don't need to be tested and adding coverage later than you didn't need.  You may not realize it until you've done TDD for a long time.   And as a result what you can end up with is having is a nightmare to where you change a line of code and have to change 200 tests, many which are not even directly related to the line of code you just changed, because your test suite is too focused or focused on stuff you don't need to be adding coverage for.

5) I find that when I Test Drive all new code, I usually end up with higher test coverage to begin with 

Rather than tack on a ton of tests after new code and hope and pray they're even valuable or wondering if I am testing the right things and that I'm hitting some goal of code coverage, I find that I end up with at least 70% code coverage most every time I TDD a new feature.  

And I'll humbly admit that this is only because I've worked my butt off to try to learn it and at the same time had the rare opportunity to pair with people who already know TDD well and learned from them how to do it the right which is why I end up with a higher percentage of valuable tests, higher test coverage, and can trust them and testing the right things but it's always a learning process...and I'm continually learning how to get better at it and always will be.

Conclusion

In the beginning, it's better to forget this code coverage goal and to learn how to do TDD right and to get comfortable with is so that you can see it's benefit which is where it starts to get fun.  This is only done through persistent practicing of it and if possible be practicing it with the right people.

When I say "right people" it's not to imply snobbiness.  It actually means the opposite, to find people who already know it well and had success with it and learn from them because it will save you a lot of pain and you'll learn ten fold and save hours of wasted time reinventing the wheel and prevent you from making common mistakes that newbies make that a seasoned TDD developer can point out and prevent you from doing or answer many questions as you go about pairing with them.  

The worst thing is for a business or team to try to become a TDD shop when there is nobody on the team who is seasoned already at TDD who can help pair and train the team for a good period of time first, and then at the same time, your dealing with the boss who just cares about goals of % of code coverage as the most important metric to deliver back to upper management for the end of the year.  You'e just going to delay focusing on what's really important, getting TDD right and seeing truly it can do for the team.

Wait till you get comfortable with TDD, and you learn how to write better tests, and start to see its value, then start worrying about coverage %.

Windows 8 install "GPT partition style" Error and Resolution with OS X Yosemite

You're trying to setup dual boot with Windows 8 on your Macbook Pro.

You've done the following:

• Created a bootable Windows 8 installation USB drive created by the boot camp utility in Yosemite

And after all that, you boot up and assume to select that boot-able USB drive in order to install Windows 8 with it:

But then during the Windows 8 install wizard, you select the partition you expect to be able install Windows 8 on and on the selected partition you've gotten the infamous error "Windows cannot be Installed on this disk. The selected disk is of the GPT partition style".  You try to delete the partition and attempt to recreated it and format it and yet it still doesn't rid this error.  Nothing you do works...and you're about to give up.

You've pulled your hair out a few times and you are now bald.

What do you do?

Boot up using the EFI boot partition first instead:

Once you select the EFI boot drive, it'll kick off your bootable BootCamp created USB Windows install drive and this time the windows 8 install wizard will be fine and you will not see this error when selecting your partition in which to install Windows 8 on.

I am sure I've had this very same pain before in prior Mac OSX or my previous Macbook Pro laptop, but I just did not remember.  So now I'm blogging about it so I do remember next time and so it hopefully reminds others ;).