Archive for General

Raspberry Pi as a WOL server

My electricity supplier in the UK recently sent me a electricity consumption meter which tracks energy use in real time and displays in on a small LCD panel. This has proved to be a real eye opener for me and has helped me to see how much power is used by a variety of devices in the house. I’ve found myself checking the meter at regular intervals and I’m getting good at working out which things are powered on just by checking the meter!

Electricity Consumption Meter

Electricity Consumption Meter

I’m one of those geeky types that likes to leave my home PC on all the time. This means that when I’m away from home, I can connect to the PC remotely and pick up files or refer to old email archives that I don’t keep on my laptop. I haven’t given this much thought until now but I checked the power consumption of my PC and saw that it draws 250W – 300W whenever it’s powered on. I did some rough calculations to see what this was costing me and I was surprised.

Daily power use for my PC = 0.275 KW x 24 = 6.6 KWh
Annual power use for my PC = 6.6 KWh x 365 = 2409 KWh
Average cost in the UK for 1 KWh = £0.14

Annual cost for running my PC all the time = £0.14 x 2409 KWh = £337.26

This made me think about turning my PC off more (as my wife has been suggesting for years) ;-)   But I don’t want to lose the ability to turn it on remotely and get access to files….. hence my use of WOL (Wake on Lan).

I recently bought a Raspberry Pi and I’ve been tinkering with it for a while, I’ve used it for time lapse photography and general experimentation. I’ve also put one in the Trust IV office in Manchester which operates a webcam. I thought that I could use the low-powered Raspberry Pi to wake up my high-powered PC when I need it and I’d enable power management on the PC to put the PC to sleep when it isn’t in use.

Here’s how I did it.

  • Installed a base build of Raspbian on my Pi
  • Installed “wakeonlan” on the Pi, using the command [sudo apt-get install wakeonlan]
  • Installed Apache on the Pi, using the command [sudo apt-get install apache2]
  • Installed PHP5 on the Pi using the command [sudo apt-get install php5]
  • Wrote a small PHP script that sends the wakeonlan command to my PC.
  • Changed the default port for the webserver
  • Enabled port forwarding on my router to forward HTTP requests from outside to the Pi.
RPi screenshot

RPi screenshot

The PHP script (above) is pretty straightforward and uses the “exec” command to simply execute the wakeonlan command. I may improve this to give myself some visual feedback to show that the magic packet has been sent to the PC. For now I’m just happy that I can reduce my energy consumption and still access my PC remotely whenever I want to.

Assuming that  this gives me a 50% energy saving, this should reduce the electricity bill by more than £150 per annum.

At a “fork” in the superhighway

Yesterday I was reading this article from TechRepublic which promtped me to write a blog post for Trust IV. I’ve decided to reproduce the article here so that some of my more regular readers might find it.

Browsers have come a long way since Tim Berners-Lee developed his first browser (WorldWideWeb) in 1990. In 1993 NCSA Mosaic became the defacto browser for early adopters of the Internet and this browser is credited with popularising the world wide web. Many of today’s browsers have evolved from this early browser as shown in my simplified* “browser family tree”. (Click image to download .pptx file)

Browser evolution

Browser evolution

 

At the heart of each browser is the browser engine. This is the code that takes content from HTML, CSS, JS and image files and displays it on your screen. The browser engine is transparent to most users but it can be important. Changes in browser engine are important for both functional and non-functional testers. Functional testers may come across a website that “works” for one browser and doesn’t work on another browser, or displays different behaviours when tested with different browsers or browser versions. Performance testers may encounter sites that perform well in one browser, but not in another.

This week the Mozilla foundation announced that it was collaborating with Samsung to develop a new browser engine (Servo) to take advantage of the greater performance from multi-core architectures (which are now common in PCs, laptops and even smart phones). At the same time, Google has announced that it will “fork” the Webkit engine (currently used by Chrome, Konqueror and Safari) and develop a new engine (Blink).

Why this matters to testers (and you).  Early performance testing was all about making simple requests for page content, then timing how long it took for the web server to respond to the client request. Web pages were often static, and rendered quickly in either IE or Firefox (the prevalent browsers from year 2000 onwards). Internet connections were slow and the bulk of the time that a user spent waiting was download time.

Nowadays things are different. Multiple browsers are available (some optimised for mobile use). This means that the same web server may serve different content based on browser version. Some users are likely to be on high speed internet connections and others will be using 3G or Edge on a mobile device.  As the number of browsers increases it is still possible to test in “the old way” but testing in this way is becoming increasingly less valid. I often find that my clients are interested in realistic page response times for users, rather than simply the time taken to download content.

For example, I used a private instance of WebPageTest to measure the page response time for the TrustIV website. For a new user with no cached content the page downloaded in 1.8 seconds but the page was not visually complete (from a user perspective) until 2.9 seconds had elapsed. Which of these response times would/should I report if this were a performance test?

 

WebPageTest screenshot

 

With low end performance test tools, all I could report on are the page download times. This is fine in many cases where a period of iterative testing is carried out to improve performance and find bottlenecks. But what if there’s a problem in client-side code? Unless my test tool takes the time to render the content I’ll be mis-reporting true end-user performance to the client.

Choosing a test tool
Some of the higher end performance test tools such as LoadRunner, SilkPerformer, SOASTA and NeoLoad render content using one or other of the browser engines. This gives an indication of true page load times, but not all test tools can do this. It’s important to fully understand your client’s browser types and the limitations of your test tools before you try to advise your customers on probable end-user response times. This is even more true now that there are 6 browser engines “in the wild”, rather than the 4 that we knew about last week.

I’m looking forward to hearing from the major test tool vendors about how they’ll adapt their test tools now we’re at yet another “fork in the road”.

Fork in the road

 

 

*I based my “browser family tree” on information from a number of sources including the Wikipedia “timeline of web browsers” and the wonderful interactive graphic from “evolution of the web

Using Buffer to schedule “Tweets”

If you’re a user of social media, you may have heard of the social media tool called Buffer. In case you haven’t, it’s basically a sharing and scheduling tool which “buffers” outbound tweets and then sends them  in the future. I use it for Twitter, but it can also be connected to Google+, FaceBook, LinkedIn and so on (if you have a premium account)…. For me the free one works just fine.

Buffer differs from other Twitter scheduling apps because you don’t have to manually schedule tweets, you set a timetable for when you want tweets to go out and Buffer automatically tweets at the predetermined times.

You can fill your buffer in a variety of ways:

  • Emailing tweets to a private email address
  • Via the web interface at https://bufferapp.com
  • From your smart phone
  • Through Firefox, Chrome or Safari browser plugins (not IE … yet).

This is great and I’ve noticed more activity and engagement from my followers since I used Buffer. Unfortunately, I couldn’t think of a way to populate multiple Twitter accounts without paying for the premium version….. until now.

 

Buffer screenshot
Buffer screenshot

As you can see from the screenshot above, I have access to three Twitter accounts. My own account @richardbishop, my company account @TrustIV and the @VivitWorldwide account. By logging into Twitter in three browsers, I can stay connected to each of them and use the different plugins to populate my Buffer.

In the screenshot above, I used Chrome, Chrome Canary and Firefox and installed the Buffer plugin in each of them. This allows me to paste Tweets between the browsers if I want the same message in multiple accounts or post to individual Twitter feeds if I want to. Each of my accounts has a different schedule and it is possible to share my non-personal Buffer account with the other users of the @TrustIV and @VivitWorldwide Twitter accounts.

Are You a Human? – CAPTCHA replacement

I’ve noticed a lot of automated registrations on my blog recently (despite using Akismet to deter spam). Deleting these fake user accounts every few days has become a pain in the neck. This reminded me of plugin that I read about last year which claims to be more effective than CAPTCHAs and can help deter automated user registrations on your site.

The Are You A Human plug-in helps to distinguish humans from bots in a more enjoyable way than forcing users to read images of corrupted words. The games are simple,  mildly amusing and according to the Are You a Human website, are generally faster than a text CAPTCHA.

Are You A Human plug-ins are available for WordPress, Drupal, Joomnla, nodeJS, phpBB, PHP, dotNet, Java and others so the chances are it could be used on your site if you have this problem.

I installed it in about 5 minutes on my site and it seems to work really well. Click on the image below for a demo of this in action. Alternatively try to post a comment below and use it “for real”.

Are You a Human

“Technical debt” – now a mainstream term

moneyI wasn’t surprised to read an article on the BBC news website explaining that UK banks (and more importantly their customers) are likely to experience more “software glitches” in 2013. The likelihood of problems increases as systems age, experienced technicians leave through free-will or redundancy and corners are cut to meet project deadlines.

I was surprised however, to read the term “technical debt” in the mainstream press. Normally this term is consigned to the “geek world”. Technical debt builds up in computer systems for a variety of reasons, as outlined in the article.

  • Increased complexity of systems
    This is exacerbated by mergers and demergers which force IT systems, never designed to co-exist to be “made compatible” with each other”. Rather than rewriting code, or migrating to a new shared platform designed specifically for the purpose, a sticking plaster approach is taken. This works in the short term but increases system complexity (and risk) in the long term.
  • Under-investment and a lack of modernisation
    Rather than invest in upgrades, the “if it isn’t broke, don’t fix it” mentality is allowed to predominate. This is sensible in the short term but builds up problems for later.
  • Outsourcing
    It’s harder to modify somebody else’s code than changing your own. As well as this, after outsourcing or off-shoring becomes entrenched in your organisation  your in-house teams may  lack the skills to do this work. This leaves you more reliant on the external contractor than would be desirable.

Technical debt, like other debts needs to be paid in the end and unfortunately UK banks are finding this out the hard way. The well-documented, recent problems with Faster Payments, NatWest batch jobs and Knight Capital’s trading errors will be the tip of the iceberg. There will be a significant number of “near misses” that go unreported.

Testing, why bother?

The article goes on to mention testing and says that ”Modern computer systems are so complicated you would need to perform more tests than there are stars in the sky to be 100% sure there were no problems in the system”.

This may be true, but all testing is important and good testing can (and does) flush out problems that otherwise can go on to cripple banking systems. This leads me on to another major risk factor for banks and other sectors.

Who is doing your testing?

School children aren’t allowed to mark their own homework, so why do you allow your IT project teams to do it? Testing best practice says that the test team should be separate from the development team. This helps to prevent problems from being brushed under the carpet by a development team that is desperate to get their code deployed so that they can move onto the next project or invoice the customer.

Agile development methods have tended to merge testing and development teams (for good reasons). Testing becomes an inherent part of the software development work, reducing the likelihood of big problems at the end of a project.

Having said that, in my opinion; regardless of your development techniques it is vital to get at the very least an independent review of your tests. Ideally a separate team should complete your testing. Otherwise you can’t even start to quantify the technical debt building up within your systems.