One of my favorite shows on TV these days is (don’t laugh) the show Property Virgins on HGTV. In it, an experienced Realtor walks first-time home buyers through the house selection and offer process.

A lot of times the “let’s watch a couple pick a house” type shows highlight the inexperience of the buyers. Buyers tend to focus on the wrong thing, like paint colors or light fixtures, and gloss over things that are hard to change, like room layout. But the best part of the show happens right at the beginning, in a brilliant move to reset the usually unrealistic buyer expectations.

At the beginning of the show, the host asks the buyers a few key questions to identify both their budgetary constraints as well as their aspects of a home they most value. It could be location, layout, lot size, etc. But the buyers always have some sort of dollar amount they won’t go over.

The next step the Realtor does is rather brilliant – they take the first-time home buyers to a house that meets all of their aspects for an ideal home. It has the perfect layout, the perfect location, all the amenities they want, in the right condition, at the right size and so on. The buyers inevitably love this home, at which point the Realtor asks the buyers to guess how much the home costs. Also inevitably, the buyers are pretty far off the actual price, and inevitably their ideal home is typically at least double, if not triple or quadruple the buyers’ budget.

And inevitably, the buyers have sticker shock!

Talking buyers off the ledge

This fantastic approach accomplishes two important goals:

• Convey what perfection costs
• Force a prioritization

The host is never mean about showing the expensive house, but instead presents it as something to aspire towards. This also resets in the buyer’s minds that every house they see from there on out is going to have some subset of their valued aspects.

But instead of discouraging the first time home buyers, this approach tends to force them to focus on what is most important to them in a house.

Resetting expectations

We often have clients that are first-time software buyers, or first-time-with-someone-who-knows-what-they-are-actually-doing software buyers. A lot of what we do in the initial part of the project is framing the project for success. We look at everything the client wants, talk about scope and budget, then reset expectations back down to an attainable level.

What we don’t want to see happen are those buyers that look at dozens or even hundreds of homes looking for that house that checks every single checkbox and comes in at their budget. That house might exist, or it might not, but a lot of time can be wasted searching and searching.

Constraints force prioritization and hard decisions. Having an experienced guide (like that Realtor host) ensures that the buyer understands what’s feasible for their budget, as well as the guiding hand on helping to share experience on what things matter (the electric wiring needs replacing) or do not (the bedroom has shag carpet).

Delivering value is really only half the equation. It’s up to us as developers to make sure the buyer understands what they are getting for their money (or time), relative to what’s out there in the market. If you bought a house in isolation, it’s hard to know whether you’re getting taken to the cleaners. But by having frames of reference (Product XYZ is similar to yours, and took ABC man hours/dollars to build), we can center the conversation around “what’s most valuable to me” instead of “how can we squeeze everything in”.

Did you get it right? Learn how to be predictable with HP LoadRunner!

Software testing practitioners, managers and consultants provides in this article illuminating, educational and funny anecdotes about their experiences with test automation. The key points of each story are put in evidence. You will see that * Technical success is not a guarantee of lasting automation. You need management support through good communication. * After the abandon of  automation maintenance, it is likely to die. For a better chance of success, you should choose an automation approach that will require the least maintenance. * Automation should start before the software being tested is delivered, so ...

In this article, many people share their illuminating, educational, and funny anecdotes about their experiences with test automation.

When lives are at risk if systems fail, it is critical to minimize defects through the best software engineering processes possible. High-maturity processes are valuable for delivering quality, mission-critical software and supporting overall project ...

Sometimes, work can be difficult without the proper mindset. If you’re tired, angry or frustrated for instance (like Patriots fans this morning) then you’re almost guaranteed to make some careless mistakes. This is true of almost every profession. Software testing in no exception.

So what’s the proper mindset for a software tester? Much has been written on the topic – and it’s critical to your success in the field – so I figured I’d offer a view different points of view.

Here’s one from softwareprojectmanager.com:

A professional tester approaches a product with the attitude that the product is already broken – it has defects and it is their job to discover them. They assume the product or system is inherently flawed and it is their job to ‘illuminate’ the flaws.

This approach is necessary in testing.

Designers and developers approach software with an optimism based on the assumption that the changes they make are the correct solution to a particular problem. But they are just that – assumptions.

Without being proved they are no more correct than guesses. Developers often overlook fundamental ambiguities in requirements in order to complete the project; or they fail to recognise them when they see them. Those ambiguities are then built into the code and represent a defect when compared to the end-user’s needs.

Here’s another view from onestopsoftwaretesting.com:

Pedantic, sceptical, nit-picking to software

Some years ago, we were asked to put a slide together, saying who makes the best testers, and we thought and thought, but eventually, all we could think of was, they’ve got to be pedantic and sceptical and a nitpicker. Now, if you called someone a pedant, a sceptic, and a nitpicker, they’d probably take an instant dislike to you. Most folk would regard such a description as abusive because these are personal attributes that we don’t particularly like in other people, do we? These are the attributes that we should wear, as a tester, when testing the product. When discussing failures with developers however, we must be much more diplomatic. We must trust the developers, but we doubt the product.

Most developers are great people and do their best, and we have to get on with them – we’re part of the same team, but when it comes to the product, we distrust and doubt it. But we don’t say this to their faces. We doubt the quality of everything until we’ve tested it. Nothing works, whatever “works” means, until we’ve tested it.

Impartial, advisory, constructive to developers:

But we are impartial, advisory and constructive to developers. We are not against them, we are on the same team. We have to work with them, not against them. Because it is human nature to take a pride in their work and take criticism of their work personally, bear in mind this quote: ‘tread lightly, because you tread on their dreams’.

Here’s a similar view from kualitatem.com:

All software must possess bugs as the developers are human and you can’t eliminate the error factor from humans. Therefore it’s very important for the tester to think from end user perspective and try to find out all the possible bugs that a user can face. The approach to use Mindset Testing is to treat the software as it’s full of bugs; the developers deployed an application that will crash when end-user will use it and testing its all possible flows. Here begins the work of a tester to find out all these bugs and loopholes that will make this application go crashing.

Don’t take any bug lighter, “Report all bugs you have encounter with”, as you will be responsible for it at the end.  Although sometimes with the mutual understanding of the developers and QA, some bugs are not addressed right away, but still, from QA perspective one should not skip reporting any bug.

What do you think? Is there a proper mindset for testing? If so, what is it? Please share your thoughts in the comment section below.

This article walks you step by step through using open source tools like JMap, VisualVM, BTrace, and EurekaJ to effectively diagnose performance and memory problems in your Java apps.

This article provides a detailed description on how use Pex and Moles to generate unit tests for a project having external dependency(WCF Proxy) using Visual Studio 2010 SP1. The Pex tool, which automatically generates test suites with high code coverage, will be used to generate unit tests. Moles allows to replace any .NET method with a delegate. They will be generated to isolate the external dependency (WCF proxy) and behavior will be redefined using delegates.

The Functional Testing Tools Directory presents a list of commercial or open source functional software testing tools like Selenium, Cucumber or JBehave. The web site also proposes pointers to tools reviews or presentations and contains a page of resources associated to functional software testing. Visit http://www.functionaltestingtools.com/

 

Join us Tuesday, February 21 at 11:00AM (GMT-0500) for a 30 minute demonstration of Nexus 2.0, with Jason van Zyl, Sonatype Founder & CTO. You’ll see all the new features and learn how Nexus 2.0 will help you:

• Avoid downtime by using a highly available architecture
• Improve repository management with enhanced component information
• Standardize on a single repository for .NET, Java, and OSGi

Reserve Your Seat

If you register, you’ll also receive access to the recording after the event. So if something comes up and you can’t make it, you won’t miss out.

I’m kicking off 2012 conference season with what should be one of the top conference I will have the opportunity to attend this year. The Mobile World Congress is THE place to be if you’re involved in the mobile world. The annual attendance is generally between 50,000 and 60,000 people! Theme for this year is perfect: Redefining Mobile.

As mobile takes more and more importance into the life of consumers and become a primary focus for Enterprise business, we at SOASTA are trying to stay ahead of the game and provide the best testing products to address this ever growing market. As you know, we’ve announced our new mobile test automation solution a couple of weeks ago and so far the feedback is INCREDIBLE! We’ve held our biggest webinar in our history for the occasion and we’re looking for a repeat 2 weeks from now at a convenient time for our European customers. I’ve been doing demo of our new technology all last week and it really opens up some very interesting discussions and open a realm of opportunity for developers and testers. The fact that we don’t rely neither on simulator/emulator or OCR makes complete sense for them. They’ve been abandoning these inappropriate approaches for a while now and are looking at investing into what looks to them the only way to properly test their apps. Being able to test INSIDE the app, record every single events, actions, gestures received by the application is very, very appealing. Being able to use validations they’re familiar with because they’re CloudTest users is also a definite plus. They’re also very excited about the concept of Private Device Cloud (and by its possible public extension!). As you know, when testing with TouchTest technology, your devices don’t have to be tethered. It means that I can run a test on a device located on the other side of the world for example. Now imagine, a company having 3000 employees and developing mobile apps. Before TouchTest, to validate your application on a broad number of devices, you had to either buy the actual hardware or rent some VERY expensive lab provided by third party relying on OCR. Wouldn’t it be nice to leverage my employee smartphones to run my tests? When you think about it, they all have different smartphones you app should support (whether it’s iOS, Android, Windows Mobile, etc.), they’re all connected to different carriers … They’re a very good representation of your market! Because TouchTest doesn’t require your devices to be tethered, you can tap into this pool to not only run functional tests on all of them but also capture performance information during execution! Oh, and you don’t have to mess up your employee’ smartphones because TouchTest doesn’t require jailbreaking. How about that for redefining mobile test automation? Definitely a game changer the industry was expecting.

What’s also very interesting to notice is that every single customer we talk to about mobile test automation, is also interested to hear about our solution for load and performance testing. Validating functionally the application running on an actual device is one thing. Making sure that the full ecosystem the application rely on, whether it is the customer’s backend/infrastructure or third-party, is probably as important in 2012. Being able to reproduce actual traffic whether it is coming from desktop’s browser or actual mobile devices is today a reality every customer wants to take advantage of. Having one platform covering the whole end-to-end test requirement is key to them.

My goal at the World Congress will be to discuss our new technology with application developers and testers to get their feedback and ideas. Meeting with companies to understand their challenges testing their apps and show them that they don’t have to go back to the dark ages (aka manual testing) to ensure the robustness of their deliverable. I also want to discuss with potential partners who wants to provide the best technology to customers and are willing to be part of the best ecosystem today for software testing. In the past few months, Correlsense, AppDynamics and OpTier have join our rank to provide the best services to customers and I’m confident I’ll have some great conversation with partner with a compatible DNA so we can strengthen our platform.

I will also formally meet a number of Spanish customers during a business breakfast and roundtable organized by our partner Testabil. There are still a few seats left so if you’re interested to participate, drop me a note at fberinger [at] SOASTA [dot] com! It would be great to meet you!

This is going to be an AWESOME week!

• Tweet This!
• Share this on Facebook
• Share this on LinkedIn
• Share this on Reddit
• Email this via Gmail
• Stumble upon something good? Share it on StumbleUpon

Get Shareaholic

Related posts:

1. Mobile Test Automation the SOASTA way with TouchTest
2. Getting started in mobile web performance
3. Is the world cup killing Twitter?
4. Cloud Testing days in London – Join me!
5. The Cloud: A game changer to test, at scale and in production, SOA based web and mobile applications.

I released version 0.4 of Jezebel last week. It now works with Node.js 0.6.2. Ben Rady

Unit testing is essential in order to ensure that your code does what it’s supposed to do.

But, as much as Typemock is a firm believer in unit testing, well, let’s be honest — it’s not fun.

As our CEO recently put it in Dr. Dobbs, “Unit testing is like staying healthy,” argues Lopian. “Staying healthy requires best practices such as eating right and working out. Similarly, development teams need the right practices in order to innovate faster. Just as it’s hard to start working out, many find it’s hard to unit test and thus stop — despite its well-known benefits”

But unit testing frameworks have many problems.

Some of them include:

1. Lack of Automation – Yes, you can write manual tests and do everything manually. You can also code in Notepad or another text editor. For some, that’s fine – witness the text editor wars in Linux – but others prefer a robust IDE and toolkit. Automatic unit testing saves time, allows for more robust testing,  and allows for tests to be run repeatedly. But even many automatic unit testing frameworks, like xUnit, or mocking-only frameworks don’t let you test much of your code unless you go 100% by the book with excellent design. Most of us simply don’t have code that can be adequately tested by even the most robust open-source frameworks, leaving us (and our business or product) vulnerable to bugs and technical debt.

2. Focus on test instead of code – The goal is working code, delivered on time. But, too often we forget this, focusing on our tests. But, this allows a disconnect between our test and our code. When a test fails, what does that mean for my code? When it passes, how do I translate that into working software?

Frequently, while we know that a test failed, we don’t always know where the error is. This makes it harder to achieve our goal – getting code out in time that just works.

3. Takes too much time – In our high-stakes development environment, frequently understaffed and overloaded, every second counts. Sometimes, we’re also tempted to shortcut now and save time up front – of course we’ll pay for that later but later is abstract when your boss is breathing down your throat. And, yes, even when you have the luxury of doing TDD by the book on greenfield code, it still takes time up front (of course it will save you time overall, but when the release is due, try telling that to your boss).

Currently, most unit testing frameworks run your entire code every time you make a minor change. If you’ made a minor change, you still need to rebuild your code from scratch. That’s time that you just don’t have when your code is overdue. Each change takes time and seconds turn into minutes and hours.

Frameworks need autocomplete – shaving time – and to just run the code that changed.

4. Weak mocking – Require TDD and good design first – can’t deal with legacy code – Simple greenfield code is a nice fantasy but it’s not most projects. What is needed is a framework that can mock complex legacy code, privates, statics, etc. Most frameworks don’t offer powerful mocking or the ability to test legacy code, new code, or even unwritten code.

5. Coverage – Too many frameworks don’t let you know what’s covered and what’s not. Yes, as Uncle Bob said, coverage is not the most important or only metric and 100% code coverage may not always be the ideal.

But, too often, we don’t know what code is covered and what code is insecure.

 

Leave a comment – what are some things you find lacking with unit testing frameworks. Feel free to tweet as well using hashtag #tddfail

 

It’s time for a change.

Luckily, change is coming.

Stay tuned.

Can’t wait? Discover unit testing tools and practices this Wednesday and enter the raffle to win an Isolator license.

Want more webinars? Sign up!

Typemock is hosting a webinar about how to test dependencies and legacy code. The webinar will be on Wednesday February 8 at 8:30 PM (20:30) India Standard Time.

You may have already started unit testing or at least understand the basics. But there’s one large obstacle that stands in your way: dependencies. Most code was not written to be easy to test. How can you test dependencies? Join this webinar and learn different methods and tools that help create unit tests to test dependencies and legacy code.

Learn:

• Why you are writing legacy code

• Hand rolled mocks

• Mocking frameworks

• What makes a good unit test

This webinar is intended for .NET developers interested in automated unit testing who want to learn how to develop better code.

You can also win a Typemock Isolator license or t-shirt. You must attend for the chance to win

To sign up: http://www.typemock.com/unit-testing-dependencies-and-legacy-code

I saw a blue being from another dimension clawing its way through the ceiling the other day.

If only.

The building I work in is being redecorated and on the way to the canteen  I noticed that the painters had covered a smoke detector with a rubber glove. You don't need to be a health and safety officer to realise that this is not standard policy and potentially risky.

But, paint fumes can set off smoke detectors and there were plenty of people around and there are many other smoke detectors in the building and the lack of other detectors covered with gloves suggested that decorators would be likely to remove it when they'd moved further down the building so I decided to do nothing about it. A clear spec violation, but mitigated by other factors. A reasonable short-term solution to an acute issue, but on the way home I still walked that way and checked that it had gone.

You'll sometimes hear testers described as pedantic and it's true that the detail and process-orientated aspects of our work are apt to be misinterpreted as (or can actually slide into) the rigid adherence to requirements.

It's not worth getting worked up about the term itself because, for example, to people who operate at helicopter altitudes on projects, the details are often just that, the details, the potential stains on the big picture and not their main focus or responsibility. And let's not kid ourselves. It works both ways and I'm sure you've got a few favoured adjectives for the teams you work with on a regular basis.

It is worth thinking about whether the description has some validity, and trying to demonstrate that it's not a fair blanket description of testers all the time. Look at yourself and wonder whether (a) now is the right forum and time for raising questions of detail; (b) whether any particular wrong you're concerned about really is not right given all the context or (c) whether despite being wrong it's also perhaps not not right for now and (d) whether you should monitor it and/or record the need to change it later, when it's more likely to be invalid and risky to have a spot fix buried in the codebase.

I've been pretty quiet in recent times, but that's going to change somewhat in 2012, so I thought I'd write this(*) to catch up.

As of last week, I am the QA Lead for the Wikimedia Foundation. My job there will be to create, codify, and execute the software testing and quality assurance regimes for the software that powers Wikipedia and its associated properties.

I've worked some other interesting places, among them Thoughtworks and Socialtext. I like open source and wikis. I have been a dedicated telecommuter/remote worker since 2006. Depending on when you read this, I'm in either Santa Fe NM or Durango CO, or somewhere else.

I have written about software a lot. Most of my writing in recent times has been for SearchSoftwareQuality.com  (warning: registration wall), but I've also written a lot for StickyMinds.com  and a couple of articles for PragPub.   I wrote a chapter for Beautiful Testing.

I created the Writing About Testing peer conference and associated mail list and wiki. I like to think WAT has had some influence on the testing/QA field over the last couple of years. I've given presentations at a couple of Agile conferences, once at PNSQC, a couple of AWTAs, and some smaller peer conferences from time to time. I attended two GTACs.

I've been using browser automation tools (Selenium  and Watir) since they existed. I know a lot about their history and something about how to use them well. As a programmer I am slow and simple. What programming I do is usually in Ruby.

I play fretless electric bass guitar with a couple of jazz bands, but outside of the WAT conference I'm more well known for playing irreverent tunes on a cheap green ukulele at software conferences.  I'm a pretty good musician.

I'm @chris_mcmahon on Twitter, christopher.mcmahon at gmail and gplus. I ignore LinkedIn and I don't have a Facebook page, don't try to reach me there.

* props to Warren Ellis, from whom I stole the idea of this post.

New webinar from CloudBees and Codesion - CollabNet Cloud Services:
Tuesday, March 6, 2012 10:00 AM - 11:00 AM PST

At this very moment, software development and deployment practices are shifting monumentally…to the cloud! The cloud provides significant advantages that allow organizations to substantially improve efficiencies and delivery times at a much lower cost, reducing the overall total cost of delivery of applications.

Exploit the cloud? Get even better at Agile? Save time and money?

If any of these concepts pique your interest, you’ll enjoy this new webinar from luminaries at CloudBees and Codesion, the Cloud Services arm of CollabNet.

CloudBees VP of Products Steve Harris, CollabNet VP of Products and Engineering Willie Wang, and CloudBees Solutions Architect Jim Leary will enlighten you on how to easily and cost-effectively…

• Get started developing and deploying applications in the cloud
• Improve and expand your Agile practices using the cloud
• Exploit the cloud to accelerate the development and delivery of quality applications
• Modernize your continuous integration and deployment process and methods

If you want to spend more time writing awesome code and less time managing your environment, register for this webinar.

Willie Wang
CollabNet VP of Products and Engineering
Jim Leary
CloudBees Solutions ArchitectSteve Harris
CloudBees Senior VP of Products

Testing usually means looking for bugs in software. But to Sport Evac, it means ensuring everyone gets out of a stadium safely in an emergency situation. The software was designed by the National Center for Sports Safety and Security and tests every scenario imaginable to help security personnel and first responders at big sporting events prepare for an emergency. But, as it turns out, testing is testing whether you’re testing the latest mobile app or an evacuation strategy for the big game. The goal is to find as many of the nasty bugs as you can before everything goes live. FoxNews has more on Sport Evac:

The Sport Evac program trains teams for those “what if” scenarios, by creating virtual 3D stadiums drawn from actual blueprints and packing them with up to 70,000 animated human avatars designed to respond to threats as unpredictably as their human counterparts.

It’s advanced technology fans won’t see on game day — but tech that behind the scenes makes watching the big game safer.

Evacuation in the event of an emergency is a critical challenge, and rehearsing the how to move around tens of thousands of people isn’t realistic. So sports security planners turn to computers to make sure it all goes smoothly.  …

The virtual stadium allows them to simulate how fans will respond in those first few critical minutes after an attack. Stadium and team security can use the virtual stadium to practice moving players and fans to safety and to run exercises with local first responders. …

As with any test, the ability to scale to meet different demands is key to success. Only testing for the “best case scenario” isn’t very effective.

Sport Evac isn’t the only evacuation software program, but others have struggled to meet the scaling challenge of sporting events. Other simulations also failed to include the wide range of human behavior variations and the multitude of factors that may disrupt the best-laid aid plans.

All sorts of curve balls can appear in a threat: parking gridlock, for example, making an orderly exit disorderly, or the elderly having a hard time with a crushing crowd.

Sport Evac allows security teams to test the robustness of their planning against the full range of possible factors — fans fighting against the stream to retrieve forgotten wallets and handbags, spilled beer creating too-slick floors, emergency lights failing and so on.

Not only did the makers of Sport Evac create and test desktop software, they are also working on a mobile app version of the software for stadium employees and first responders to use on-site. This app sounds like a perfect candidate for some in-the-wild testing because any sports fan can tell you that the middle of a sold-out stadium isn’t the best place to get a signal. Plus, this is the last app you want to crash, freeze, load slow or glitch at the exact moment you need it most.

A smartphone app, known as Sport Evac Lite, will become available as well, so security staff and ushers can see where fans and cars could bottleneck.

Read the full article at FoxNews >>>

For testers like me, coding beyond batch/routine like scripting is a bit exotic in the main. In my experience most testers are doing VBScript on you-know-which-tool, maybe some Java on pretty much every tool as it’s the defacto language it seems. There’s a smattering of Python in use but the ardents seem few and far between. Then there’s fan boys like me doing some Ruby stuff all mixed with a smattering of other languages depending on the environment the tester works in.

I guess it’s more like doing testing which involves a bit of coding, instead of coding which involves a bit of testing. It’s great if your role involves you touching code at some point a few days a week. That way you can get your coding skills up and keep them up to. A lot of testers however are looking to start coding so they can develop professionally and of course utilise it for automation, testing, etc.

One problem I found was deciding which language to pick. So, simply put:

Step 1: Pick a language

There’s a multitude to pick from, the TIOBE index (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html) is said in some circles to be worthless but if you don’t know what’s out there it’s a good start point for reference.

What are you using at your current workplace? What are they developing in? Well there’s your starter for 10. Is there a particular tool you want to get good at, which involves some coding? Bingo, go learn that then.

There are languages that are flipping everywhere. Java, PHP, VBScript, JavaScript, C, C#, C++ and of course the handy ones such as SQL and Perl that have been in utility use forever.

If you can, pick one that’s going to see you able to use it day to day, ideally one that those around you are competent in too. It’s easier to learn that way.

Step 2: Find learning Resources, make a plan

In order to learn you need to find some trusted sources of tuition, I’m assuming you’re doing self-directed study here and not going on a course. Have a look at www.codeyear.com for example, how about http://www.sqlcourse.com or just searching for “Learn [language] online” and see what comes up. There are too many resources to list but plenty to get started.

Create some form of learning plan and set yourself a goal as to how many hours you’re going to spend learning your chosen language. I picked 100 hours after a suggestion on the Software Testing Club. I have a goal but not a how-many-hours-a-week goal, I study when I can. If you can set time aside then great. Regarding a plan, simply list out what topics you want to learn and tick some off or add some more as you go.

Step 3: Share your learning

There’s nothing better than backing yourself up against a wall, putting yourself in a corner, etc. by telling the world you’re going to learn to programme. Head over to http://www.softwaretestingclub.com and start blogging about your plan and progress.

Also, have a look at www.codepad.org where you can paste snippets of code, then post the link in your blogs. Set up your free Github repository over at https://github.com, there’s an easy to follow tutorial there and it’s 3 commands day to day to maintain your library. Don’t forget to use the Wiki you get to document what you’re adding.

Overall…

Just get started, whatever you learn will be of use!

Good luck and I look forward to reading your updates.

Just shy of the end of 2011 I started to do ‘100 Hours of Testing Practice’ prompted by a post from Phil Kirkham over at the Software Testing Club. Find his post here: http://www.softwaretestingclub.com/forum/topics/100-hours-of-testing-practice

First question - does 100 hours feel a lot or a little?

It’s an odd one, if you think about how we do on average 40 hour weeks in work then it’s not a lot. If you think about how much time you get to spend on your hobbies/pass times/interests then it’ll take more than a few weeks to get 100 hours in! In those terms 100 hours is a lot.

Either way, that’s the goal that was proposed and that I’m working too. 100 hours which I’ve not decided to dedicate fully to learning Ruby ‘stuff’. By that I mean the Ruby language of course, as I’ve defined it ‘beyond simple scripting, but also automation, frameworks and tools using Ruby.

I decided a few years ago that Java wasn’t the language for me, I did a formal course with the Open University as part of my degree. It was OK, but didn’t get me excited, far too verbose even if it is admittedly ubiquitous and probably a good language to learn career wise. (never say never and all that…). Ruby got me excited, it seemed very learnable like Python but more widely used.

The Blog Posts

Since Phil’s post was essentially an invitation to participate I decided to do so and share what I’ve been doing over at the STC. Each member has a blog space provided so I’ve been blogging my adventures there.

I’m currently at hour 22 of 100 and will be officially ¼ the way through early next week. So, does it feel a lot in reality? Well, yes actually. It’s taken a good few weeks to get this far and on the way I’ve learned a fair bit. I’ve also uncovered a lot I want to look at too.

This is a side benefit, the extent of my ‘view’ on what resources, sites, blogs, books there are has increased. So has my hit list of things to look at!

A little Git!

One other side benefit too is I set up a public Github repository for the scripts I’m creating. Not only is it’s sensible place to put scripts but it’s another tool I’m learning along the way.

Have a look at: https://github.com/MarkCTest/Script-Bucket

Why not join in the fun? Read Phil’s post and get started on your 100 hours, then blog over at STC to keep everyone involved and yourself motivated!

Have fun!