Development notes: software

Joplin is pretty great because it syncs between desktop and mobile, using any backend cloud of your choice.
Joplin doesn't have an official web app, probably because it would be re-inventing the wheel.
It does have this web client (alternate link), but it's not being maintained.

There are many forks, have any been worked on?

It did have nextcloud integration, but this has not been maintained.

To do: Check those forks too

Nextcloud can be self-hosted (requires some work), or it can be hosted in the cloud by a provider.

Tomboy

Tomboy appears very linux-centric, although it has clients for Windows and Mac too.
It has an Android app, TomDroid.
It has a WebDAV plugin for publishing to the web
No web actual app

Evernote

Proprietary software
Charges actual money
Irritating business practices
Free version only allows two devices, which isn't enough

Org mode

orgmode.org
No web app

Colornote

Works brilliantly on Android
Super fast for short notes
No web app

Others

https://en.wikipedia.org/wiki/Comparison_of_note-taking_software

JetBrains just released DataGrip ( JetBrains DataGrip: Your Swiss Army Knife for Databases and SQL ). I've been using it full time during the EAP (aka "beta"). It's expensive ($90/yr or $9/mth) but very, very good. Never loses your work. Starts up right where it left off. Dark and light themes. DB specific syntax highlighting. Good stuff.

Before that I was using Navicat Premium Essentials. I got it for ~$20. It's now ~$150 which is too much given it's limited functionality and spotty reliability IMO.

re:dash is overly simple for serious use IMO. Edit: We're actually using this now. It's more of service than an SQL client. It allows casual users (e.g. not full time analysts) to run queries without any setup. Great for centralised dashboards and sharing queries. Try this before you commit to something like Periscope, Looker or Mode.

Portico (was PG Commander) looks interesting but I (personally) need to work with multiple database flavors so it's a non-starter.

SQuirreL and SQL Workbench/J are both pretty crunchy and old feeling Java apps. If you've been on a Mac for a while they will make your eyes bleed.

There is also Toad on the Mac App Store. The screenshots look Mac native but it's pretty crunchy and unpleasant. It feels like going back in time.

Update 2016–09–02: I would suggest that you also look into the “code notebook” applications that are available now, e.g. Jupyter, Zeppelin, and Beaker. You may well find these tools more useful unless you’re a full time DBA. We have replaced Re:Dash with Zeppelin internally.

Oracle clients

A short list:

dbVisualizer
Toad
Oracle SQL Developer

Cannot install Java JDK: semicolon found in selected path

There's no semi colon in the install path. But you still get the error:

semicolon found in selected path

Solution is to move the install .exe to c:\ and run it again.

Possibly with command line switches: /v"/L c:\install.log"

(Search results show that this same issue has existed for 11 years!)

Select sub-section of putty buffer only

Are you sick and tired of waiting for your terminal to scroll down when dragging to select a large portion of the scrollback buffer in putty?

The putty developers already thought of that!

Go to Putty Configuration window
Choose "Selection" from category on the left of the window.
Under 'Control use of mouse', choose 'Compromise (Middle extends, Right pastes)' if not already chosen.

(source)

Linux package managers

A list:

rpm
yum - works with rpms
zypper (suse)
pkgsrc (cross-platform, builds from source)
yast (works on suse)

Where to download oracle wallet mkstore

It looks like mkstore was the utility in 10r2 but by 11g it had been deprecated by orapki.

An article mentioning both tools.

Linux window managers

Window managers:

Mate (fork of Gnome 2),
Mint (Extensions for Gnome 3),
or Cinnamon (Fork of Gnome 3)

Gnome 2 was good, Gnome 3 was where it all went wrong, but now people are switching back to Gnome 3.

See also evilwm (joke) or xfce (supposed to be fast).

When Ubuntu's window manager went bad (11.04 -> 11.10)

(source)

Web developer browser plugins

Chrome:

Chrome itself doesn't require admin privileges to install
Chrome has dev tools built in - type F12 and select a tab e.g. Network, or right-click on the page and choose 'Inspect element'
chrome://net-internals/
Web developer plugin
Modify headers

Internet Explorer:

Internet Explorer should be installed by default
It has some dev tools built in - type F12 and then:

Menu: Find | Select element by click
Menu: Cache | View cookie information
Tab: Script | Console
Tab: Network (IE9 and later) | Go to detailed view | Double-click an item for headers and cookies

Standalone:

Fiddler2 - inspect and modify HTTP traffic (requires admin)
DebugBar (requires admin)
Proxomitron - inspect and modify headers, (does not require admin rights)

Proximodo a clone of Proxomitron (requires admin)

Charles Proxy
Other proxies

Non-GUI:

curl -D -
wget -S

(source, source, source, source, source)

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/

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

Can't install recent Perl: too few arguments to function ‘dbmclose’

When I tried to install perl 5.16.2 or perl 5.20.0:

wget http://www.cpan.org/src/5.0/perl-5.20.0.tar.gz
tar -xpvzf perl-5.20.0.tar.gz
cd perl-5.20.0
sh Configure -Dprefix='/opt' -de
make
...
make[1]: Entering directory `/opt/dweb/home/shepwil/src/perl-5.20.0/ext/ODBM_File'
cp ODBM_File.pm ../../lib/ODBM_File.pm
Running Mkbootstrap for ODBM_File ()
chmod 644 ODBM_File.bs
../../miniperl "-I../../lib" "-I../../lib" ../../lib/ExtUtils/xsubpp -noprototypes -typemap ../../lib/ExtUtils/typemap -typemap typemap ODBM_File.xs > ODBM_File.xsc && mv ODBM_File.xsc ODBM_File.c
cc -c -fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\"1.12\" -DXS_VERSION=\"1.12\" -fPIC "-I../.." ODBM_File.c
ODBM_File.xs: In function ‘XS_ODBM_File_DESTROY’:
ODBM_File.xs:128: error: too few arguments to function ‘dbmclose’
make[1]: *** [ODBM_File.o] Error 1
make[1]: Leaving directory `/opt/dweb/home/shepwil/src/perl-5.20.0/ext/ODBM_File'
Unsuccessful make(ext/ODBM_File): code=512 at make_ext.pl line 561.
make: *** [lib/auto/ODBM_File/ODBM_File.so] Error 25

The solution:

sudo diff /usr/include/dbm.h.patched /usr/include/dbm.h
62c62,63
> extern int dbmclose __P((DBM *));
---
< /* extern int dbmclose __P((DBM *));*/
< extern int dbmclose __P((void));

sudo cp usr/include/dbm.h.patched /usr/include/dbm.h

(source)

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.

What a healthy development environment looks like

In my opinion, the best set up would include:

Software

Jira for issue tracking
A wiki for information sharing
Git for version control
Continuous integration and continuous deployment (e.g. with Jenkins)
Use an existing package provider like Redhat, don't compile publicly available software yourself

Environment

Full commit history available with details of developer name and change ticket ID
Full ticket history available to read, with no historical tickets in the "old" system and unreadable
/etc/init.d scripts ('service') for starting, stopping and restarting software
VMs for development
Identical production, development and test environments
Continuous Integration: Every check-in to any development branch is run through the test suite, and any failures are emailed to the author
Immutable infrastructure: Servers are not changed. All changes begin with pushing to a repo, and a new server is then built and deployed to a subset of users, tested, then to all users.
One-touch deployment, identical in both production and development environments

Continuous deployment: Every commit to trunk that passes the test suite is deployed

Refactoring code as required, restricted only by the need to pass the test suite
All major software components described on wiki with details of source code, restarting, troubleshooting, owner, etc.

Tests

Easy to run the entire test suite for any branch
Test suite should complete quickly
A test suite that is comprehensive and well understood by all
Test coverage stats are visible to everyone
Tests for hallmarks of quality like 'use strict' and embedded documentation (even if a blacklist of legacy code is required)

Code

Clear model-view-controller separation
All code contained within re-usable modules (scripts are thin wrappers around classes)
No "utility classes" (inherit/use roles if common methods are needed)
No "god classes" (split up methods into meaningul sublclasses or roles)
All logic contained within meaningful "noun" classes designed for problem domain
Meaningful variable names in domain language and no unnecessary abbreviations
Plentiful comments, written in the language of the problem domain
All classes/modules to have embedded documentation

People

For every piece of work, three people should discuss it together for a few minutes after a technical design has been proposed, and before any development work is started - a representative of the business, a QA tester and a developer.

They should ask questions like "Are the requirements accurate and high quality?", "Does the proposed solution fulfill the requirements?", "Is the proposed solution high quality?", "Can the proposed solution be easily tested?", etc.

The product manager as well as the people coming up with requirements must be readily available to answer questions.
To facilitate communication. teams should *not* be split across timezones

(separate) Scrums should take place at the beginning of the local day

Development notes

Jump to

Quick reference

Chrome extensions: Download manager reviews

Running Emby on Linux

How to manage schema migrations (track database changes)

Note-taking apps for desktop, web and mobile

November 2021

Joplin

Tomboy

Evernote

Org mode

Colornote

Others

Mac clients for AWS RedShift

What is the best SQL client on Mac for working with Redshift?

Oracle clients

Cannot install Java JDK: semicolon found in selected path

Select sub-section of putty buffer only

Linux package managers

Where to download oracle wallet mkstore

Linux window managers

Web developer browser plugins

How to install ruby, rake, rubygems

Search engines

Good enough software

Make it easy to review your code

Windows macro recorders

Can't install recent Perl: too few arguments to function ‘dbmclose’

How to communicate within an IT department or tech team

What a healthy development environment looks like

Search this blog

Highlights

Quick reference

Links

Blog Archive

Tags

Jump to

November 2021

Joplin

Tomboy

Evernote

Org mode

Colornote

Others

Search this blog

Highlights

Quick reference

Links

Blog Archive

Subscribe To

Tags