Cloud development machines

 A list of cloud servers for basic hobby-level software development.

All prices per month:

• DigitalOcean: $4 for 512Mb memory, 10Gb file storage, 500Gb transfer
• $6 for 1Gb memory, 25Gb file storage, 1000Gb transfer
• Block storage:
• $10 for 100Gb
• Object storage:
• $5 for 250Gb, 1Tb outbound transfer
• Images: $0.06/GiB/mo
• = $1.50 for 25Gb
• Vultr: $6 for 1Gb memory, 25Gb file storage, 2Tb transfer
• Block storage: $1 per 10Gb
• Object storage: $5 for 250Gb, 1Tb outbound transfer
• Linode: $5 for 1Gb memory, 25Gb file storage, 1Tb transfer
• Block storage: $1 per 10Gb
• Object storage: $5 for 250Gb, 1Tb outbound transfer
• Images:
• $0.10 for 1Gb x 25
• $2.50 for 25Gb x 25
• Kamatera: $4 for 1Gb memory, 20Gb file storage, 5000Gb transfer
• File storage:
• $6 for 30Gb
• $7 for 40Gb
• $8 for 50Gb
• $12 for 100Gb

(source)

Outlook 2007 autocomplete doesn't work

It really doesn't.

I tried these things:

• Adding the name to my contacts list
• Composing and sending an email to the contact (source)
• Tools | Address Book | Tools | Options | Check names using these address lists | Contacts

Some names are auto-completed, but some aren't.

:-(

Do you know how to make it work? Leave a comment

Debugging Perl in Emacs

Notes only:

• http://search.cpan.org/~yewenbin/Emacs-PDE-0.2.16/lib/Emacs/PDE.pm
• http://www.emacswiki.org/emacs/PerlLanguage
• http://www.emacswiki.org/emacs/CPerlMode
• http://cpansearch.perl.org/src/YEWENBIN/Emacs-PDE-0.2.16/lisp/doc/QuickStartEn.html

Open source code review tools comparison

Options I'm familiar with for Subversion:

• ReviewBoard - good, but fiddly to install. Emails all your comments in a batch when you're ready.
• Atlassian Stash - okay but generates one email per comment. No, that's been fixed!
• Kallithea - looks good, not tried.

Perl modules for SOAP

Options/notes:

• W3C::Soap - not good
• SOAP::Lite - not as good as XML::Compile
• XML::Compile - recommended
• XML::Compile::SOAP
• XML::Compile::SOAP11
• XML::Compile::WSDL11

...but generally SOAP isn't much fun.
Expect the WSDL to be wrong, you may need to store a "fixed" copy locally.

How to install ruby, rake, rubygems

https://www.ruby-lang.org/en/documentation/installation/

For ruby, tried:

• https://rvm.io/ - wouldn't work on my Suse setup
• https://github.com/sstephenson/rbenv#readme - worked on Suse. Promising, I like.
• https://github.com/sstephenson/ruby-build#readme - doesn't work

For rubygems, tried:

• https://rubygems.org/pages/download - worked

For rake:

• It comes with ruby

Now learn Ruby:
https://github.com/neo/ruby_koans

Search engines

List:

• HP Autonomy IDOL
• Google search appliance
• Solr / Lucene
• Atlassian Jira/Wiki search
• Knowledge bases (untested):
• http://www.helpgizmo.com/
• https://www.zendesk.com/knowledge-base
• http://www.knowledgebase-script.com/
• http://www.spiceworks.com/free-it-knowledge-base-software/

Which data file format?

List:

• CSV
• TSV
• INI
• XML
• YAML
• JSON
• RDB
• custom

Good enough software

There's so much software available these days, it's difficult to find which is the best without laboriously downloading, installing, configuring and testing, which I don't often have time for. Unfortunately a large proportion of software is simply not good enough, or its features are poorly described.

Here is some "good enough" software I've found for Windows:

• To diff directories, e.g. sync music or photos: FreeFileSync 6.3
• To diff the content of files, e.g. source code: WinMerge
• Windows Explorer alternative: xplorer 2
• To encode mp3s: LAME
• To see where your disk space is being used: Treesize
• To remove spyware: Spybot: Search & Destroy
• Torrents: qBittorrent
• N64 emulator: project64
• Programmer's text editor: Notepad++
• ebook management: Calibre
• Manage iPhone music outside iTunes: Media Monkey
• Graphics maniplation: GIMP
• Rename files: Bulk Rename Utility
• Macro recorder: Autohotkey
• Media player: VLC, or MPC-HC (not tried)
• Music player: Winamp
• Documents and spreadsheets: Microsoft Office
• (LibreOffice and OpenOffice are NOT good enough)

Make it easy to review your code

tldr; It's difficult to arrange for a whole team of developers to follow and participate in code reviews, but if you use dedicated code review software then it's easy.

Of course you want a wide audience reading your code - in order to improve the quality of the code being produced by your team. You don't have anything to hide, do you? ;-)

Problem: Say you're not the "designated reviewer", and you want to see your team mates' code before it's merged to trunk, perhaps the following things have to happen:
    - Configure your email filters to pick out reviews from the hundreds of other update emails
    - Check out the code in your environment
    - Wait some time for the checkout to complete
    - Run a diff command to see the changes
    - Hope that your team is using version control tools which make it easy/possible to see only the commits they made, without mixing them up with all the code that was pulled from trunk/master along the way
    - Read the code
    - Copy and paste the lines of code you want to comment on (for context) into a message to the developer. As it's often easier and faster to use email, instant chat or a face to face meeting than adding comments to a bug tracking system, the rest of the team isn't part of the conversation and is denied the chance to learn about technique, see how to conform to house policy, etc.
    - Write the comments
    - The developer reads the comments and may or not make changes, you don't always know, and the rest of the team certainly doesn't know.
    - In a team where developers are expected to designate a single person to review each feature, attempting to give feedback on someone else's code out of turn could be seen as interfering and a distraction.

Solution: A better arrangement could be:
    - Use a code review tool: ReviewBoard, Stash or something similar
    - Click on a URL in the review notification email
    -  Read the code
    - Click on the line you want to comment on
    - Write the comments. The whole team gets notification emails of comments, so they can effortlessly follow along with conversations about the code.

    - The developer replies to the comments publicly, everyone is now aware of what technical decisions were made and why

    - Everyone is expected to review all code - it's not distracting because it becomes part of the general work of the team to ensure high code quality.

Windows macro recorders

List:

• EZ Macros - good but very old
• AutoHotkey - very good
• AutoMate - ?
• Workspace Macro - ?
• Auto Macro Recorder - not intuitive, and I don't like the interface. Looks like Windows 3.1

How to communicate within an IT department or tech team

Communication is difficult, it's easy to get wrong. Here are some ideas about how to get it right.

• Mailing lists: Make them public (within the company). Archive them. Make them discoverable. Let users administer them. See GNU mailman.
• Wiki: Only have one. Keep the software up-to-date. Have an 'information architect' role, who manages the structure, so that the information is in predictable places. Make sure the search works (test it regularly). Unlock all the permissions. Let people delete pages. React to user feedback.
• When you upgrade, ideally migrate/import the data to the new version. If that doesn't happen, then export or otherwise safely archive the old content. Publish it internally, make sure it's available, even if static.
• Use the Gliffy plugin or equivalent (e.g. on Atlassian Confluence an open source wiki) or equivalent to allow users to publish diagrams of unlimited complexity, that can be edited and kept up-to-date by anyone.
• Issue tracking system: Keep the software up-to-date. Don't install a million plugins (looking at you Jira) that make it difficult to upgrade. Make sure the workflows match reality, give people standard ones and document how they work. Be very careful when making changes to workflows, try to keep them as general and re-usable as possible.
• Write high quality tickets.
• Service Desk: Use the same system as the bug tracker, which will allow all staff to track their tickets' progress in a way they understand. If this is not possible, make the service desk ticket system no less usable/visible than the staff issue tracker system.
• Ensure the service desk issue system is no less usable than email, i.e. original message chain quoted in all replies, and CCs honoured with reply-all.
• Have a special email address for people to CC which will copy the email to a ticket. Publicise it regularly.
• Choose software that makes a healthy development environment.
• Things to publish internally, and regularly re-post:
• instructions for transferring phonecalls internally
• instructions for setting up a conference calls (for all phone models in use)
• instructions for setting up video calls from conference rooms
• instructions for setting up a laptop/desktop with the big screen in meeting rooms/presentations
• List all regular non-stream tasks, define roles to triage, co-ordinate and communicate them to the rest of the team, with a view to improving and streamlining the work of the team. Examples:
• Failing tests
• Environmental issues
• Live bugs
• Supporting the release
• Inter-team liaison
• Monitoring reports
• Business investigations
• Ideally don't have any remote members of the team. But at the very least, don't inconvenience the co-located members for the sake of remote members. This means:
• Don't hold scrum via phone or skype, hold it in person. Figure out some way for the remote people to attend that doesn't take anything away from the people in the room. If there's no way, they can attend their own scrum, or not at all.
• Update: Video chat (e.g. Zoom) works well when there is a large TV screen and dedicated room microphone device. Whoever is in the office goes over to that TV & mic area and starts the video call so anyone working remotely can dial in and participate.
• Don't force people to communicate via headsets when they're standing next to each other. That would discard the many benefits of face-to-face communication.
• Make sure everyone actually stands up around a physical board (Update: Jira scrum/kanban board works fine over video chat, if updated outside the meeting). If headset range is too far to work, don't use them.
• Don't have the scrum at a weird time of day to accommodate other time zones.
• If it's difficult to hear the remote members then have them email points to the team.
• Try to arrange for the remote members to work one-on-one with each co-located member, to build rapport
• Put ALL work in the issue-tracking system to make it visible, even non-development work. If it's not tracked, you didn't really do it. Each task must link back up to team "epics" or long-term goals, and ultimately to a company goal. Must be extremely easy to create tasks with one line of text and no other info, i.e. prevent unnecessary overhead for simple tasks.
• Specific to large companies:
• Instant chat client for ALL members of staff, with zero configuration, it's just there waiting to be used. Hooked into Outlook and the O/S so that it knows when you're in a meeting or away from your desk and updates your status accordingly (e.g. MS Office Communicator)
• Have a meeting room booking system that is painless (is this even possible?) and transparent with regard to: higher-ranked employees permission to "override" bookings, policy for block-booking rooms every week, etc. Above all it should be obvious what is happening and why.
• IRC/Slack or equivalent for all. Make it clear that all communications will be logged.
• (crazy idea) Employ a person/team whose sole remit is to make it easier to communicate within the company. This is definitely not the usual "Internal Communications" team that sits with HR and serves the Executive. It's a team that is there to support IT workers.
• If the office is very large, publish a map of where each team sits. Make sure it's always up-to-date, either by giving a team the responsibility to do it, or making it editable by anyone on the wiki.
• Link from the team map to official wiki pages, etc. org chart, make everyone's names and roles discoverable and visually represented.
• Put signs up around each area so you can see which team sits where.
• Use scrumblr.ca or funretro.io or similar (virtual post-it note boards) for retrospectives, to allow ideas to be captured throughout a sprint, not just on the day. Also a wiki page does just fine. But it's also important to keep real, physical post-it notes and pens in the meeting for people to jot down ideas they just think of at that time.
• Create the following types of wiki pages, for each team or development group:
• Tech Debt / Yak Shaving / Infrastructure to-do list / Ideas / Suggestions (use your judgement if this should be one page or several). This is a list of things that people want to do, changes they want to make that are not on the roadmap, or don't obviously provide direct value to the business. The team may need help explaining where the value lies.
• Proposed technical discussion topics. Topics worthy of group discussion. Schedule a regular meeting (every 2-4 weeks) to discuss whatever is on this list and make a decision as a team about how to proceed.
• Developer FAQ. Either per-team or per-department.

Source: My own experience working in IT.

Comparison of private image hosting

• Facebook - Private albums, but I never quite trust them with my privacy. Interface is tedious and buggy to use. Not geared towards organising lots of images. Upload limit not advertised.
• Photobucket - Private or password protected albums. Interface is not great as it squashes your thumbnails, has adverts and only shows a few images each page (mobile). 10Gb free, $30/year for 20Gb, more storage available.
• Flickr - 1Tb free. Pictures can be private, or shared with family. For pictures, this is very good. Uploaded video quality can be poor. Interface is great for uploading and organising many thousands of photos and video.
• SmugMug - $40/year for unlimited uploads. Advanced privacy/sharing system. They've put a lot of effort into it.

I recommend Flickr.

Perl code review

What is wrong with this line of code?

return !grep { $_ == $item->id } grep { $_ } @$scanned_items;

A lot of things are implicit in it.
It returns 1 (true) if the count is zero, and "" (emtpy string - false) if the count is non-zero.

I would prefer for it to be written more explicitly:

my $item_count = scalar grep { defined $_ && $_ == $item->id } @$scanned_items;
return ($item_count > 0) ? 0 : 1;

Best Android calendar notifications

Options:

• Google calendar (built in) - notification icon only stays visible for duration of "event", so not suitable for reminding you to do something, if you don't check your phone at the right time, you won't see anything. Notifications are only visible if you pull down the notification drawer.
• isoTimer - notification stays there, but app has a slightly weird UI and is slow.
• Touch Calendar - ?

Enforcing breaks away from the screen

There's a need to interrupt oneself, to avoid spending too much time constantly staring at the screen/sitting down, etc. to prevent RSI, eye strain, back injury, etc.

• RSIBreak - Looks promising, but falls prey to multi-monitor taskbar bug and is hidden behind taskbar, also greying out of screen doesn't work. And doesn't seem to always alert me. And "lock screen" button doesn't work. Nor does "run on startup". (Ubuntu 12.04).
• Workrave - In some ways looks better than RSIBreak. Easier to configure/understand notification times, has numbers countdown instead of a clock, and suggests exercises to do in the breaks. But it doesn't match up small breaks with long breaks like RSIBreak does, so it often pops up an alert soon after I've just taken a break.

Pop-up notifications on linux

Alternatives:

• notify-send hello # works, but disappears too fast, and can easily be missed
• growl # advanced, haven't figured out how to use it
• knotify # apt-get install kde-baseapps-bin
• zenity # zenity --warning --text "meeting is now"

Hook one of these into your calendar application.

Or for IRC, using pidgin, try one of:

• Pidgin GNTP
• Growl plugin

Or write your own pidgin plugin like I did, to use a notification system of your choice:

• github - pidgin plugin

Simple small Perl webservers

Quick start, if it's just a proof-of-concept and won't be running for long:

• HTTP::Daemon - can't get simpler than this. It even picks a port for you
• HTTP::Server::Simple - it works

More complicated to set up, but much more robust:

• PSGI/Plack - the future
• lighttpd - it's pronounced lighty

Perl: Try::Tiny vs TryCatch vs Syntax::Feature::Try

From NAP::Policy (thanks dakkar):

       Using TryCatch you’d write:

         try { ... }
         catch (SomeClass $e) { use($e) }
         catch (SomethingElse $e) { use($e) }
         catch ($e) { use($e) }

       Using Try::Tiny you’d write:

         try { ... }
         catch {
          # here you get the exception in $_
          when (match_instance_of('SomeClass')) { use($_) }
          when (match_instance_of('SomethingElse')) { use($_) }
          default { use($_) }
         }; # note the semi-colon

       On the other hand, if your TryCatch use did not have a unqualified "catch ($e)", you need to write "default { die $_ }" to re-throw the unhandled exception (yes, you really have to write "die
       $_", read the documentation of die to learn the ugly details; "die" without arguments won’t do anything useful there).

       Also, keep in mind that the blocks used by Try::Tiny are actually anonymous subroutines, so they get their own @_ (nothing in the case of the "try" block, the exception in the case of the
       "catch" block), and "return" will return from the block, not the containing subroutine.

      Devel::Declare (via TryCatch) is deep scary voodoo.


From #backend:

• Try::Tiny is the less magical and scary (and fragile) version of TryCatch
• Syntax::Feature::Try is currently the least offensive of the alternatives, but it has quite a way to go
• it does nasty things with the call stack
• preferrably it would splice the optree, like a compiler macro
• How does return work? TryCatch returns from the surrounding sub, Try::Tiny returns form the try {} block

Email gateways

I want to write my tweet in an email and have it tweet for me, because I don't like most twitter clients. Email is also available on all devices (like old blackberries) where there aren't good apps.

• ping.fm - used to work, but it got shut down
• ifttt.com - couldn't get it to work
• everything else - closed