Now that my first screencast has been finalized and published online, I thought it would be a good time to share insights into the things that I learned while producing it. You’ll see that what initially seemed to be a pretty straightforward task, turned out to be a quite a bumpy ride indeed.

The first, and probably biggest mistake I made, was to assume that the production of a screencast resembles anything close to the prep and delivery of the regular training sessions that I normally conduct. Talking to a live audience is much more forgiving and natural than making an impersonal recording. For me, it felt like the screencast uncovered all the weaknesses and dark sides of my communication abilities. 

Despite your best efforts, it is very difficult to deliver a natural-sounding script during the screencast. I eventually realized that the best method to use was to focus more on what I wanted to demonstrate, in terms of individual steps and important points, than to try and meticulously plan out a script. 

I would advise to start recording raw version first. Focus on showing the information that is important and try to talk it through set-by-step. Don't worry about saying something stupid, making mistakes or mumbling: that's all very natural. Recording made me realise how difficult is to focus on doing something while speaking about it at the same time.

When you’re happy with the recording (which might take several re-edits), review what you said and make appropriate corrections. I think that the best way to approach this is to write it all down. The trick is to use the edited version as the basis for your voiceover; it will make your speech much more relaxed and natural sounding and you don't have to worry about timing, because as long as you're watching the video track at the same time it's easy to get in sync.

I found that splitting both the recording and the voiceover into 3 - 6 minute long segments provided valuable checkpoints. Although the length of the screencast really depends on the target audience, it is worth noting that, in my (limited) experience and based on the first viewing statistics, it seems that the majority of viewers tend to give up after watching the video for 20 minutes or so. If you really can't get finish within this time, it's probably best to split the screencast into several parts.

With the right tools editing can be easy. My software of choice is ScreenFlow for Mac or Camtasia for Windows. Both share similar features like multi-layer editing, trimming, audio and video adjustments, callouts, and also provide streamlined workflow.

While the software you use makes the difference when editing, it’s the microphone you use that can be the real showstopper. My original voiceover was recorded using an everyday Bluetooth headset. Looking back I admit it was foolish to think it might work. The audio quality was just awful, and spending time trying to clean it up/adjust it was not worth the effort. I really would recommend that you buy a semi-professional microphone like Rode Podcaster; it is certainly worth the investment (especially if you're thinking about podcasting/screencasting on a regular basis).

Permalink | Leave a comment  »

Sorry, this post and the screencast is currently available only in Czech language.

Celý příspěvek, společně s dalšími informaci najde na Blogu DevOps česky.

Pokud vás screencast zaujal, a chcete se dozvědět víc o automatizaci infrastruktury a deploymentu (nejen web) aplikací, přijde na školení, které pořádám 1. - 2. listopadu 2011 v Praze.

Chef - Základy automatizace infrastruktury

Pro získání slevy 10% použijte kód SCREENCAST.

Permalink | Leave a comment  »

In last 10 months I became a terrible procrastinator. By the end of the summer, it had reached critical level. Whilst day-to-day work remained more or less reasonable, the long-term productivity imploded. The reason? A dramatic change in my daily routine and significantly different working style. 

Beginning in February, I stopped working 9 to 5, and, as a result the so-called 'normal working day' disintegrated into patchy fragments. The only way to get back on track was to find ways how to better organize my work and time to regain productivity.

Here's what helped me so far:

• One inbox became a necessity. Regardless of saying that the tools don't matter I found OmniFocus extremely helpful. Everything goes there - emails, short notes, tasks, errands, ideas - you name it. It doesn't matter if you rigorously follow GTD practices or not. Having one inbox guarantees nothing will slip out of the radar. Individual tasks might fall behind, but except in few extreme situations it's not a showstopper.
• Time boxing improved my ability to do one thing at a time. With Pomodoro technique it's easy to split everything into 25-minute chunks, short enough periods to overcome the temptation to do something different, and yet just long enough to get something done. After while I found that I tend to plan almost everything in pomodoros.
• Limited distraction achieved by opening email only during the time dedicated for it. Same goes for Twitter. And anytime I have a sudden, eart-shattering idea, I simply add it to OmniFocus inbox, where I could get back to it later.
  Still, I found sometimes, that's not enough. The temptation to lose focus was always there. Until I learned to switch off Wi-Fi completely when not needed. Try it. You get used to it after while. When you overcome the urge to Google everything life becomes much simpler. You begin to remember things again, and you improve battery life (laptop's, not yours) as side effect. 
• But, ultimately, the best remedy against distraction proved to be pen and paper. I bought some Pukka A5 manuscript pads and a nice roller ball, and Eureka, it worked! I re-discovered that scratching notes and concepts down on paper is fast, efficient, and much easier to visualise. Also returning to previous notes feels natural. 
  Initially, I scanned almost every handwritten page straight to Evernote. Now, I trust the paper even more and scan notes only from time to time. Event this post was originally written by hand.

All in all, these little changes helped me to get back on track, despite my challenging daily routine. That's something I can work on later… :) 

Permalink | Leave a comment  »

    It is not the strongest of the species that survive nor the most intelligent, but the ones who are most responsive to change.

    something Charles Darwin didn't say, but everybody thinks he did

First things first. Let's accept this - we're not so clever. That's why we suck at managing the change. And don't be afraid to admit it. It's natural. Who pretends otherwise is just seeking ways how to cushion the awkward truth. You might cover it by fancy frameworks, hide behind endless bureaucracy or blame somebody else. Your choice.

Permalink | Leave a comment  »

Goods require shipping. Software should not. Despite the IT industry successful move to detach the release management and need to physically transport the product, the ‘shipping’ is still creeping into the software development nowadays. Well, it’s even worse - it got embedded into our thinking. We don’t release, we ship. Those two became synonyms. What’s wrong with that, you ask?

Permalink | Leave a comment  »

We talk about it all the time - agility. At GoodData it’s in our DNA. We understand being agile is not necessarily easy. You need the right people, attitude and tools. And exactly as we’re trying to deliver the GoodData platform to help our customers bring agility into a BI arena, we need the very same tooling internally to sustain the pace of a 14-day release cycle. We bring our customers new features every two weeks - unheard of in the stodgy world of BI and analytics.

Permalink | Leave a comment  »

Priorities do change, but old habits die hard. The luxury of having more than 10 or 15 hours a week for my personal software projects is now history. To keep up means to adapt. In last 6 months I’ve embarked on a personal quest to protect the last development activities and to be able to stay up-to-date with the latest technologies. This is a practical review of what I’ve found out and what works for me (so far).

Permalink | Leave a comment  »

UPDATE 2009-10-12: I’m happy to let you know this post is not longer relevant. Amazon AWS team successfully deployed the fix and the scenario used to simulate Denial of Service attack using UDP flood isn’t applicable anymore. All that in less than 24 hours after publishing the link on Twitter. Good job!

Original post follows.

Unfortunate events surrounding the DDoS attack against BitBucket kicked-off heated discussions about the nature of this vulnerability. Where Amazon officially acknowledged this to be a single isolated incident, many others started asking questions why did it happen in first place?

• Was BitBucket’s security group configuration set to block UDP traffic?
• How come they haven’t got better visibility of the on-going attack?
• Is this really Amazon’s fault?

Both personal and professional interest led me to find out more. Having designed series of tests how to replicate this scenario, I’ve started first instance and set up the target environment.

instance : c1.medium (us-east-1d)
EBS volume : 200 GB attached to (/dev/sdf)
monitoring : vmstat, netstat, iptraf, Amazon CloudWatch
security group : allowed SSH only (port 22/TCP)

UDP flood set up to be generated from the second instance (c1.medium) using simple Perl script, managing to generate whopping traffic of 650mbit per second (according to iptraf) using 1KB packets to random ports on the target IP.

Test 1. Let it run has been successful in a way there was no visibility on target machine. Still surprised by the traffic level generated on the source box, I’ve pointed the UDP flood to another machine – with security group allowing UDP traffic (ports 0 – 65535) – to check if the network traffic is able to reach another box. And it was. Not only from the same availability zone, but even from the different ones (tested us-east-1c and us-east-1b).

Test 2. consisted of formatting the prepared EBS, 5 samples for both scenario with and without UDP flood.

No traffic (1m15s)
UDP Flood (2m54s)

During the test there were only moderate increase in IO waits (somewhere between 2 – 4%).

Test 3. Bonnie++ performance test of the EBS volume. Running with no incoming traffic, it took around 8 minutes to produce quite reasonable report. Having switched on the UDP flood I’ve repeated the same tests and my expectation was to see some results in similar time. Fifteen minutes later and bonnie still haven’t even finished third step (rewriting). Another 10 minutes without any significant progress pointed me to do some research what’s going on. The box wasn’t performing virtually any IO operations, and time spent waiting for IO topped 100% every second reading (1s delay). Bingo!

To verify if the problem is really caused by incoming UDP flood, I’ve stopped the traffic for a brief interval (around 7 seconds) and monitored using vmstat:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
0  1 893480  11272   3112 1699240    0    0     0     0   10   11  0  0 66 34
0  1 893480  11272   3112 1699240    0    0     0     0    9    6  0  0  0 100
0  1 893480  11272   3112 1699240    0    0     0     0   10    9  0  0 67 33
0  1 893480  11272   3112 1699240    0    0     0     0   11    8  0  0  0 100
0  1 893480   8824   3100 1700052    0    0 23808 24864  962  697  0  1 68 31
0  1 893480  12284   3084 1697988    0    0 16384 16576  711  424  0  2  4 93
0  1 893480   9020   3084 1700088    0    0 20480 20720  817  563  0  1 68 31
0  1 893480  10432   3072 1700192    0    0 20864 20720  907  612  0  4  5 90
0  1 893480  10976   3040 1699724    0    0 15620 12432  588  423  0  1 68 31
0  1 893480  10872   3044 1698556    0    0 12676 16576  600  350  0  2  2 96
0  1 893480  10328   3024 1700676    0    0 19976 16576  761  535  0  1 68 31
0  1 893480  12408   3004 1698096    0    0  8708 12432  457  254  0  1  4 95
0  1 893480  12408   3004 1698096    0    0     0     0    9    7  0  0 67 33
0  1 893480  11636   3004 1699120    0    0  1024     0   38   38  0  0  0 100
0  1 893480  10548   3004 1700420    0    0  1280     0   47   45  0  0 66 33
0  1 893480  10188   3004 1700756    0    0  3584  4144  195  110  0  0  0 100
0  1 893480  10120   2992 1697968    0    0  6404  8288  256  205  0  0 67 33
0  1 893480  12468   2992 1696864    0    0  8064  8288  343  250  0  0  2 98
0  1 893480  11720   2972 1696984    0    0 12420 12432  495  333  0  0 67 32
0  1 893480  10136   2976 1700800    0    0  6916  4144  321  190  0  0  0 100
0  1 893480  11972   2956 1698820    0    0  4096  4144  161  117  0  0 67 33
0  1 893480  11364   2960 1699480    0    0  3844  4144  200  126  0  0  1 99
0  1 893480  11432   2960 1699480    0    0  2944  4144  160   91  0  0 66 34
0  1 893480  11156   2960 1699820    0    0   256     0   18   12  0  0  0 100
0  1 893480  10884   2960 1700020    0    0   256     0   17   17  0  0 66 34
0  1 893480  10856   2960 1700076    0    0     0     0    9    8  0  0  0 100
0  1 893480  10856   2960 1700076    0    0     0     0    9    9  0  0 67 33

As you can see on line 5 the IO traffic resumed, roughly correlating to the time incoming traffic stopped. Seven seconds later with the UDP traffic back on the box tried to keep up for another quarter of minute before giving it up.

Nothing! Based on my notes the first bonnie run occured at 10:40, switched on the UDP flood at 10:50, and started second bonnie run at 10:52. My patience ran out before 11:30 where there’s small peak caused by interactive iptraf session.

At this point there were no reasons to continue testing. All IO operations to/from EBS volume seemed to be blocked by UDP traffic generated by a single instance!

Conclusion

BitBucket guys had every reason to be angry. Blocking UDP in the security group configuration only hides the problem. Contraindicating the Jesper Nøhr statement, during this experiment there were no peaks visible using paid monitoring service – Amazon CloudWatch (see above). Which was probably the amount of information available to AWS 1st line of support.

This corresponds to the ‘black box’ described by Jesper. Looking back on the results it’s obvious that

• on-demand network capacity backfired in this case
• security group configuration is most likely applied on the host system
• host architecture seems to be sharing same network interface(s) for actual network traffic as well as network traffic to/from EBS instances. Even though instances got only a single network interface, I would expect this separation to be implemented on the host system. Segregation of the network traffic is one of the first lesson learned in high-exposed clustered environment.
• a week after the attack and there isn’t any fix in place. Hello, Amazon?!?!

To be fair, it’s been the first incident of such a magnitude. Let’s hope Amazon AWS team will come up with the architecture fix before somebody use the vulnerability in much wider and devastating attack. In mean time, the only workaround we can apply is to hide our instances as much as we can. Load-balancers and proxies in front of the worker instances should be enough, as long as you don’t share the same host machine.

Have a good weekend and good luck protecting your instance’s IPs!

PS: who had the same dark thought as I just had? What about S3?

[UPDATE 2009-10-11 7:00pm] c1.xlarge instances are able to generate UDP flood in the rate of 800 mbps. I guess, Amazon AWS is running 1Gbps network infrastructure.

Permalink | Leave a comment  »

Following the rocket like boom of the cloud computing by the end of 2007, countless questions have been asked about security aspect of such a solutions. For many businesses this concern may overshadow other benefits – like agility, cost effectivity or scalability. This post is my reflection on true considerations one should take into account when moving into the cloud; all in perspective of the small to medium size businesses.

Many articles and studies casted a dark shadows on the general idea of on-demand provisioning of infrastructure. And they are right in one perspective: if you are not able to provide adequate security measures to your local hosted data or solution, you won’t be any better in the cloud (well, almost). Added remote access will only exponentially increase number of the potential intruders. But where this shadows do not reveal complete truth is the fact the lack of security is very often given by inability or negligence in businesses itself to establish adequate security. Which is not only the problem of small business, as we learned last year (2008) by series of blunders going all the way up to the British government.

Going back to the security of the cloud offering, where increased number of the security threats is anticipated, providers are (hopefully) taking preventive measures in place which we, regular users, wouldn’t be able to afford locally, especially in situations where the expectation is to bear the upfront cost of such a protection – no matter if it’s a physical equipment or operations staff (it’s up to you to pick the one more expensive for your business). As there’s no vendor able to address all the possible aspects and requirements, many of them choose openness to allow partners to provider added services. Perfect example of such a cooperation is the community surrounding Amazon AWS. Service aggregators will and have already started filling in the missing picture.

Other reactions are continually disputing physical security of the cloud computing and how such an anonymous solution can replace traditional collocation, dedicated or managed hosting services. It may sound bold, but I feel confident to say not only it can replace them but it certainly will, unless their are proactive in their offering. Based on personal experiences with even the most reputable companies on the market today we have to accept the accidents do happen, always due to the good old human factor. Especially when operation support is focused on an individual and very often not related resources, rather than anonymous blobs managed as a whole. Luckily traditional hosting market is not sleeping and we can already see different cloud based services coming from companies like Rackspace (Mosso) on one side and UK2 (vps.net) on another. To polarize the opinions a bit more I can’t wait who will knock in a final nail in the coffin of the companies refusing to change by introducing hosting platform provisioning on top of the existing clouds.

Due to the varied nature of the different cloud computing services it would be outside the scope of this post to list all the different security concerns, recovery scenarios and long-term viability options. This make selection of the provider important task, but the point is the process itself hasn’t changed so much compared to what we already know. Cloud computing is changing IT as never before, but it’s not technical rules that are changing (they’re evolving), but the business model is where the revision is being done; the rest is just a reflection of it.

Permalink | Leave a comment  »

I love my Epson V750. It’s a remarkable scanner with price tag that won’t ruin your budget. For a little bit over £500 you can’t get anything better. With one exception, the original film holders are difficult too use and way to flimsy for scanner’s professional ambitions. Luckily, there is a solution for this problem - Dual MF Film Holder (120/200) from betterscanning.com.

After superb communication with Doug Fisher, I expected to wait eight days for new parts to arrive as recent huge demand depleted his inventory of components. Exactly as promised, nine days later I received shipment details and not very long afterwards Royal Mail delivered my new film holder and ANR Insert.

I won’t exaggerate if I say the film holder is everything I was hoping for. Its solid and very well made construction is easy to use. T-Lock insert system provides necessary support to keep film almost perfectly flat.

Many users of V700/V750 scanners reported unsatisfactory quality of scans. Unlike dedicated models there is no option to adjust and focus the scanner’s internal lenses. That may result in lack of sharpness in the final image. Original holder provides height adjusters to change default height between the film holder and document table for about 1mm.

Doug Fisher’s Dual MF Film Holder allows highly improved adjustment. I haven’t tried the maximum height you can achieve, as the optimum height for my scanners is between 1.6 and 1.8 mm. Although the process requires a bit of patience, it’s still pretty easy and once you get your focus right you’ll be rewarded by adequate sharpness.

Well, I can continue going through the rest of the features, but it will be just repeating what is already written on the original pages for this fantastic product. I haven’t got chance to try ANR Insert, but expecting it to be perfect for longer panoramic film.

If you have V700/V750 and scanning 120 films, don’t wait and get one. You won’t regret it. Only thing I can do is to express thanks once more again to Doug Fisher for very smooth transaction and perfect product

Permalink | Leave a comment  »