launching windows 8 on a vm

Posted on by
3

My “Windows computer” is a Windows XP machine that is over 7 years old and barely works. I still have it because every once in a while I’ve used it to test something in Internet Explorer. It doesn’t have the latest patches, virus scan, software etc. And it is really slow. My work computer has Windows, but that is meant for work. I’m about to start on something where at home it would be convenient to have easy access to Windows. I already have a href=”/tag/virtualbox/”>VirtualBox on my Mac for Ubuntu and Chrome OS.

I decided to go with Windows 8 because it is the future.  No time like the present to start getting used to that OS.  My theory is that it will less aggravating using it for little things rather than waiting for it to become my primary computer one day.

Plus you can test out Windows 8.1 Enterprise for free for up to 90 days.  PCWorld has a great article about it.  The install was between 30 and 60 minutes.

Once the VM was installed, it was fairly simple to get started:

  1. Download JDK from Oracle and install
  2. Click down arrow in bottom right corner to get list of apps
  3. Type “Command” to get the DOS prompt.
  4. Right click “Command Prompt” to pin to start menu so can get to it right away next time.
  5. Update path from control panel

Overall, my first impressions are that Windows 8 is very colorful.  And that if I didn’t know what to search for, I wouldn’t have found what I needed.

Second impressions

They moved everything.  I’m able to do what I need, but it feels like someone moved around all my furniture, hid some things and said “well, you just have to ask for them.”  I am so glad that I don’t have to do work on this thing at the moment.  And it feels like it takes a lot of clicks to do anything.

Communicating with the VM

You can copy/paste from VirtualBox.  I decided to use github instead though as I already have the code I want to try on Windows in a private github repository.  Github has a Windows client.  I’ve never used it so decided to download to see what it is like.  It is only 41.2MB, but downloaded really slowly.   The app provided a UI to clone a repository in github which it automatically checks out into Documents/github/repo-name.  The UI is nice, but I wound up using the git bash shell provided with the application.  Which meant it really only saved me some setup.

Other options would have been Dropbox or just use the copy/paste functionality from VirtualBox.  (I really didn’t want to do that for whole files.)

ant vs java – using ** to match directories

Posted on by
Reply

Suppose I have the following files:
/MyFiles/dir/a.txt
/MyFiles/dir/child/b.txt

In Ant, this is how you write code to output all text files in any subdirectory of a “dir” directory.

<fileset id="jb" dir="/MyFiles">
  <include name="**/dir/**/*.txt" />
</fileset>

<pathconvert pathsep="${line.separator}" property="out" refid="jb"/>
<echo>${out}</echo>

In Java, the equivalent is

public class MyPathMatcher extends SimpleFileVisitor<Path> {
  private PathMatcher matcher =
     FileSystems.getDefault().getPathMatcher( "glob:**/dir/**.txt");

 @Override
 public FileVisitResult visitFile(Path file, BasicFileAttributes attrs) throws IOException {
   if (matcher.matches(file)) {
     System.out.println("File " + file);
   }
   return FileVisitResult.CONTINUE;
 }

  public static void main(String[] args) throws Exception {
    MyPathMatcher dirs = new MyPathMatcher();
    Files.walkFileTree(Paths.get("/MyFiles"), dirs);
   }
}

The Java documentation says “Two asterisks, **, works like * but crosses directory boundaries. This syntax is generally used for matching complete paths”. Whereas in the Ant documentation, “When ** is used as the name of a directory in the pattern, it matches zero or more directories.”

The Ant approach probably feels more natural to me because I’ve been using it longer. But the Java approach seems more logical because it doesn’t have the extra slash that doesn’t actually get matched.

why test driven development is “harder”

Posted on by
Reply

While I still don’t always do test driven development when coding at work, I do a lot of it.

I don’t always do TDD

  1. If I know the exact shape of the code before I start, it’s easier to create that shape before writing tests.  This happens a lot in web app development or when using generated code or certain framework.  I still write the tests with the code though. I think this happens because the interface I’m constrained by isn’t where I start thinking about the problem. When working on libraries or within a method/framework I do still TDD.
  2. For spikes.  If I have no idea how to approach something and just need to experiment.  I don’t know what tests to write because I don’t know what to do.

Ok, let’s suppose you’re working on an algorithm

This is something I find to be a great starting point for TDD.  It’s fairly obvious what the interface should be and most of the thought is on the implementation.  It is also a great example because you’ll want to try the same test cases repeatedly as you work making TDD save time.

Great, what makes TDD harder?

It’s not really.  The problem is when developers aren’t fluent in JUnit.  If the person coding isn’t good at writing tests, that becomes another thing to think about.  And when the mental load is higher, the task is harder.  The solution to this is to practice writing tests and get better at it.  Instead, some people merely complain that testing is hard and “expensive.”  Which becomes a sell fulfilling prophecy.

An example of how this affects me

I can think of three testing libraries that I’m at different levels of comfort with. And my reaction to writing a test in them. (just a regular test, forget about TDD here)

Library Comfort level Reaction
JUnit Fluent TDD, no problem.
HtmlUnit I have enough experience to know how to do common things and where I’m likely to hit a problem requiring more time. (I’m using it to test an app I didn’t write which makes things harder). While I’m comfortable writing tests, I’m limited for TDD.  I can definitely use TDD when fixing a bug.  But I couldn’t write a new screen that way.  I need the app to work enough to make sure my HtmlUnit test is right.
Selenium I know enough to know it changed a lot since I last used it. While my comfort level is a lot lower than HtmlUnit, I have the same feeling about TDD.  I could use it to fix a minor bug presuming there is enough app for me to test my Selenium code.  (And yes, Selenium as an HtmlUnit driver now which probably accounts for the similarity in reaction)

While I do have different feelings about TDD based on comfort level, one of the biggest differences is time.  It would take me a lot longer to write a Selenium test than a JUnit test.  That’s a sign that I need to practice/learn more/gain more experience.  Which is a perfectly normal part of coding.  We do need to plan for this.  Telling your developers to test with a tool they aren’t fluent in and not recognize it takes longer is a perfect way to invite no tests, poor tests or the quality of the code slipping.

Why was I thinking about this?

I’m working with someone on what I thought was an outline.  He suggested “I think a good way for us to communicate about these topics might be to first imagine …  questions we’ll want to ask”.  Kind of like TDD for an outline.  Think of what the student needs to know and get the “curriculum” from that.  I’ve never done that before and it was a lot harder than just writing an outline.  And I think the reasons it is “harder” are the same as for people new to TDD:

  1. A new way of thinking – I’ve never written questions before the objectives before.  People new to TDD aren’t used to thinking about how to test before they write the “real” code.
  2. Lack of experience with the “tool” – While I’ve written a fair number of questions, I’m by no means at the point that I feel fluent in doing so.  I’m probably just under where I feel with HtmlUnit in terms of experience there.  I know where many obstacles are but am still surprised often.
  3. More balls in the air – Just like thinking about both the tests and code in TDD, I had to think about both the questions and topics.

What is the takeaway

“Harder” doesn’t always mean harder.  Sometimes it means you need more skills and practice.  So if TDD seems “harder” to you, don’t run screaming.  You’ll get there.