I have written and spoken many times about the importance of getting started. This is a key idea in agile software development (or for that matter, to many other kinds of work). If you refuse to start projects until you fully understand how they can be completed, you will miss many valuable opportunities.
When in doubt, start. But start with a modest budget, because there is an opposite and equally unavoidable fact of life. To complete a project of any size (one person-hour, or 1000 person-years), a sufficient effort must be mustered. Sometimes some of my fellow agile lists talk about working on a huge project one bite at a time, planning just the next few iterations, just the next scrum, whatever. This is all good, this is all agile. But it is important not to ignore the size of the thing you’re trying to accomplish.
To accomplish something of size (fast enough for it to be valuable) requires an approximate overall understanding of its size, then committing sufficient “resources” of all kinds:
The list goes on
If it is not possible to commit enough firepower to the job at hand, then the right time to cancel or rescope an effort is at the beginning, not halfway through (the infamous point at which you are 90% of the way done but have 90% of the work still remaining). Keep that in mind next time a project is proposed. Understand the resources that can be committed, the overall scope of the project, and if they don’t fit, pick a different project.
I frequently work on projects where various developers are using various editors or IDEs. Some of these tools, and it would be rude to name names, have completely broken notions of how files and lines ought to end. Those of us who been working with text files for many years mostly agree on the following.
Every line, including the last one, ends in a newline character.
No trailing white space.
Happily, git will point out problems of this nature, and many editors can easily fix a file once open. But I often need to fix a whole tree of files at once. I have various snippets and batch files around to do this, here is the relevant one-liner for OSX:
Here’s a tip for the intrepid out there who are following the Angular 2 alphas. It has been somewhat harrowing, as alpha software tends to be. Here’s a problem I encountered today, and could not find an obvious answer anywhere on the Internet, therefore this post.
Here’s a critical piece of background, I have been using JSPM to manage dependencies in my Angular 2 work. I am using an alpha package manager with an alpha module loader to load an alpha framework and it’s mostly-alpha dependencies. Realistically it is surprising that it sometimes works at all.
I made the mistake(?) of falling behind a couple of weeks in the alphas – rather than updating one at a time I leapt directly from 37 to 40. With a bit of experimentation I found that breakage occurs starting with Alpha 38, and elaborate error failing to load a file Subject.js.
After reading numerous websites, Angular alpha diffs, and so on, it appears that this is related to the transition recently to “RxNext”, the upcoming next version of reactive extensions. The new dependency is visible in the top level package.json, for reasons unknown to me JSPM did not notice this and bring it in. Fortunately all of the sulfa software coordinated enough to fix the problem with a single command:
jspm install npm:@reactivex/rxjs
All of the Alpha stuff, that’s just life in your working with software on the edge. The one piece of this thing that I am a bit unhappy with is the name of the package mentioned above. This is the first NPM package I’ve encountered that begins with or otherwise includes a special character. I didn’t even know that was allowable, and I hope it does not become common practice.
Yesterday I saw the following video of a brief talk by Martin Fowler, in which he defines software architecture. I have grumbled about that term myself, in that firstly it is often ill-defined, and secondly it can be pretentious. I have sometimes defined software architecture as “high level design”, or as the design of systems complex enough to warrant substantial input from someone who is been around the block many times.
Fowler’s definition is crisp: Software architecture is those decisions which are both important and hard to change. This means it includes things like the choice of programming language, something architects sometimes gloss over or dismiss. Both aspects land squarely on the economics of software development. Said another way, software architecture is those decisions which, if made poorly, will make a project either succeed or fail, in a needlessly expensive way.
This connection resonates deeply with me. I have often talked about the economics of software development, the economic impacts of tool choices, the economic impacts of process selection, platform selection, etc. But Fowler’s talk made a connection I had never set out loud at least: the economic concerns, not only the technical ones, are software architecture.
Comments Off on Martin Fowler defines Software Architecture
At Oasis Digital, our project teams coordinate in numerous ways, sometimes by meeting “live”. At these meetings we discuss, we plan, we model, we code, we review. For teams/projects where everyone is physically present at headquarters, this is readily done by plugging in to a large TV re-purposed as a computer monitor. (Proposed bumper sticker: “My other monitor is a 60 inch Samsung”.)
For some teams and projects, though, not everyone is at our St. Louis office. Some of our developers are around the US, and occasionally projects include developers around the world. Therefore, some of our development meetings take place online, using a variety of meeting tools. Mostly these meetings are useful only at the moment they occur, but it is useful to record them for developers who are unable to attend “live”.
There are countless tools to choose from. We have had particularly good results with Google Hangouts. Unfortunately normal Hangouts has no recording feature – the recording capability is available only in the form of “Hangsout On Air”, which is more typically used to “broadcast” an online meeting. Google Apps customers, though, can use Hangouts on Air, decline to broadcast to anyone at all, then share the recording privately.
The process is not obvious. Here is how to use Hangouts On Air to privately record and share online meetings:
Consider performing all of these steps in a dedicated browser. For example, use Chrome for Hangouts, while using Firefox for other browsing. This reduces the opportunity for Hangouts (which is irritatingly bound to the browser) to interfere with other use of your computer.
Log in to YouTube. Use the Google account selector in the upper right to select your company Google Apps account, if you are logged in an more than one account.
If you don’t already have a YouTube “Channel”, which you probably don’t, click to create one. It is harmless, since for this Hangouts On Air purpose you don’t need to every actually publish anything to your “channel”.
Click “Video Manager”. The button for this is not in the most obvious place (the left navigation), rather it is along the top, and small.
Click Live Events.
Click to create a new live event.
Give your meeting event a name.
The description, keywords, etc. do not matter, since you won’t be publishing.
Adjust the setting to make it Private. This is a vital step, don’t miss it.
Don’t share it with anyone yet. That comes later.
Choose the default Quick settings, there is nothing important to adjust in the Custom settings.
Click to start the Hangout On Air. This will launch the same Hangouts app as any other Hangout – almost. As of December 2014, the features for Hangouts on Air are somewhat behind the normals Hangouts app in features and screen layout.
Click the invitation/add button in the Hangouts controls at the top of the Hangouts window.
Copy the link. Paste it in group chat so that other developers (meeting attendees) can join.
Wait for everyone to get in the meeting. Adjust microphones, webcams, speakere, etc.
Remind everyone to turn on their webcam and keep it on if possible. This provides a much better experience for anyone watching the video later – they get more of a sense of having “been there” for the meeting.
Discuss anything that isn’t part of the project in question, etc. while waiting for everyone to be ready.
Click Start Broadcast. This will start the “broadcast” to noone (because this HoA is private and not shared with anyone), and more importantly, start the recording.
During the meeting, remember that whatever is visible in the Hangouts app window, will be recorded. Adjust this regularly to keep it relevant to the discussion. Often the default behavior of switching to whoever is speaking, works well.
Remember that Hangouts On Air recordings are limited to pseudo-high-def, “720p”. Keep screen share window sizes moderate, so that text can be easily read by others in the meeting and on the recording. Sharing a full-screen at 1920×1080 or higher resolution will yield unreadable results.
When the meeting is done, Click Stop Broadcast.
Back in the Youtube Video manager, paste in the email addresses of those with whom the recording should be shared.
Don’t trust Google/YouTube to maintain privacy settings over the long term – leave the recording there until it has outlived its usefulness (a week or so in a typical project, maybe longer in a slow-paced project) then delete it.
Ouch, a 22-step process. That is the price of using Hangouts On Air in for an atypical purpose. The payoffs:
HoA works well across all major platforms, including Windows, Mac, Linux, Android, Chromebook, and more. This is the hardest thing to replace, many other meeting tools don’t come close.
The recording is immediately available privately on YouTube, all transcoding and hosting is seamless and effortless.
Google / YouTube is infinitely scalable, for all practical purposes.
No cost, for either the tools or the hosting.
Part of software (Chrome) that most developers have already installed.
Comments Off on Record Development Meetings with Hangouts On Air