My latest post on Huffington Post is “From Dungeon Master to Scrum Master: 15 Software Development Lessons from Dungeons and Dragons” and is a bit of a revamp of my D&D article from here, but geared towards SCRUM mastering and managing Software Development teams. You may find it fun and kitschy or you may find it dumb. I’m kinda’ ok with both (I’m learning that I can’t make all the people happy all the time).
A sampling of that article:
I started playing Dungeons and Dragons in about the 5th or 6th grade. I didn’t get good at it for a while, but once I did, I didn’t play much longer (insert reference to “The Best Days of My Life” here.) Dungeons and Dragons taught me a few lessons that I didn’t realize would turn out to be great life lessons, until I was much older. This childhood game taught me life lessons that I would eventually apply to the business world – more specifically, the world of software development – and I know I’m not alone. In fact, there is a distinct possibility that many a developer got their start scoping out character sheets, and many a Scrum Master began as a Dungeon Master.
Here are a few of the lessons I took away from those carefree days. And yes, this image is from a box set sitting on my table at home. Don’t judge.
1. Build a great campaign, and if the game is good, expect your players to break it.
In software, we design workflows. Then, users take routes we never thought possible. You build a product, sell the product and potentially service the product long-term. Maybe it sells, maybe it doesn’t – but if you’re not ready for the sales to happen, you won’t sell that much. How much work do you put into building a campaign, or game, in Dungeons and Dragons, if the characters are just going to go right off your script? How much effort do you put into building a business if the customers are just going to buy something from you that is completely different than what you thought you were going to sell? These are the same questions, and there’s no right answer to either (although there are many wrong answers). Understand that when momentum strikes, if you don’t have a good campaign built that is flexible, you won’t maintain that momentum. And if you haven’t thought of all the various routes a user can take around your software, you’re going to have a bunch of lost paladins mucking around in swamps with no monsters!
To read more, click here.
krypted April 10th, 2016
I love answering a question with a question. Is asr still in OS X? Is NetInstall still in OS X Server? Can OS X still NetBoot? Does System Image Utility still work? The answer to all of these is yes. Therefore, the answer to “Is imaging dead” is clearly no. Is it on its way out, maybe. Debatable. Is it changing? Of course. When does Apple not evolve?
What have we seen recently? Well, the rhetoric would point to the fact that imaging is dying. That seems clear. And this is slowly coming out of people at Apple. The word imaging is becoming a bad thing. But, as a customer recently asked me, “what do you do when a hard drive fails and you need to get a system back up”? My answer, which of course was another question was “what do you do when that happens with an iPad?” The answer is that you Restore.
What is the difference between an Image and a Restore? Yes, I meant to capitalize both. Yes, I realize that’s not grammatically correct. No, I don’t care. It’s my prose, back off. But back to the point. What is the difference between the two? Am Image can have things inserted into /Applications, /Library, and even /System (since it’s not booted, it’s not yet protected by SIP). An Image can have binaries and scripts automatically fire, that Apple didn’t bake into the factory OS. On an iPad, when you Restore, you explode an .ipsw file onto disk that can’t be altered and acts as an operating system.
The difference here is that one is altered, the other isn’t. Additionally, iOS ripsaw files only contain drivers for the specific hardware for a given device (e.g. one for iPad Mini and another for iPhone 6). But, you have pre-flight and post-flight tasks you need to perform. Everyone understands that. Think about automation via profiles. You can run a script with a profile. You can apply a profile at first boot. You can install a package (the future of packages is IMHO more debatable than the future of images) and a .app with a profile. These might take a little more work than it does with a NetInstall and System Image Utility. But then, it might not. You’d be surprised what’s easier and what’s actually harder (for now) with this new workflow. Complexities are more logistical than technical.
So, Imaging is dead, long live Restoring? Arguably, any older workflows you have will be fine for some time. So any good article has a call to action somewhere. The call to action here is to try to subtly shift your deployment techniques. This involves implementing a DEP strategy where possible. This involves putting the final nails in the coffin of monolithic imaging. This involves moving to as thin an image as possible. This involves (I can’t believe I’m saying this) de-emphasizing scripting in your deployment process. This also involves completing the move that you’ve hopefully started already, from MCX to profile or mdm-based management.
What else do you think this involves? Insert running commentary below!
krypted December 5th, 2015
According to Wikipedia, fsevents is an API from Apple that allows applications to register for notifications of changes to a given directory tree. This means that when something changes, an application (or daemon/agent) can see the change and take action or track what happened. For Linux, there’s a similar tool in iNotify.
This time of the year, a lot of imaging and packaging is going on at schools and companies around the world. A lot of people are also moving various settings out of images and into either post-flight packages, automations or managed preferences of some sort. In OS X, it’s easy to make a change on a computer and then isolate what files the change touched. Therefore, you can quickly and easily figure out what changes to make (e.g. to a property list via a management profile if you’re getting away from Managed Preferences or even to a configuration file).
One tool that can help you discover what files were changed on a system is fseventer. This small donateware app is easy to use and quickly informative. To use it, just open and click on the play button at the empty screen.
Once the tool starts running it will show you what’s changing in the background on the computer. Now make the changes that you need to make and click on the pause button.
Click on the middle button beside the play/pause button and you’ll also
Looking at the files changed then tells you what the changes are. Toggling changes back and forth and looking at the impact on the file results in knowing the changes to script/automate/profile manage for each.
You will encounter tons of apps that write generated keys here and there rather than easy to find settings such as what you see above. In those cases there are almost always command line interfaces specifically developed for changing a setting. For example, networksetup should be used to change settings that would otherwise be configured in the Network System Preference pane. This is only one of about 1,000,000,000 ways I’ve seen to do this. Happy to invite others to comment on their favorite way to track what’s changing and script it in OS X and other platforms as well.
krypted July 12th, 2012
Google recently decided that it was time to force some other company to buy cloudy dispositioned upstarts, Dropbox and Box.net. Google also decided that Office365 represented Microsoft being a little too brazen in their attempts to counteract the inroads that Google has made into Microsoft territory. Therefor, Google thumped their chest and gave away 5GB of storage in Google Drive. Google then released a tool that synchronizes data stored on a Google Drive to Macs and Windows systems.
Installing Google Drive is pretty easy. Just browse to Google Docs and Google will tell you that there’s this weird new Google Drive thing you should check out.
Here, click on Download Google Drive for Mac (or Windows if you use Windows). Then agree to give your first born to Google (but don’t worry, they’d never collect on that debt ’cause they’re sworn to do no evil).
Once downloaded, run the installer. You can link directly to your documents now using https://drive.google.com.
The only real question the installer asks is whether you’d like to automatically sync your Google Drive to the computer. I said yes, but if you’ve got a smallish drive you might decide not to. Once the Google Drive application has been downloaded and installed, open it (by default it’s set to open at startup). You’ll then see a icon in the menu bar that looks a little like a recycling symbol. Here, click on Open Google Drive folder.
The folder with your Google Docs then shows up on your desktop. Copy an item in there and it syncs up to Google. It can then easily be shared through the Google Apps web portal and accessed from other systems.
While there are still a number of features that Box.net and Dropbox will give you due to the fact that they’re a bit more mature, I’d expect Google Drive to catch up fast. And given that I already have tons of documents in Google Docs, it is nice to have them saved down to my local system. I’m now faced with an interesting new challenge: where to draw the line in my workflow between Google Drive, Dropbox and Box.net. Not a bad problem to have, really! Given the frustrations of having things strewn all over the place I’ll want to minimize some of the haphazardness I’ve practiced with regards to why I put things in different places in the past. In some cases I need to be able to email to folders, have expiring links or to have extended attributes sync between services, so there are some aspects that are likely to be case-by-case… Overall though, I’m very happy with the version 1 release of Google Drive. I mean, who complains about free stuff!?!?!
krypted May 11th, 2012
Command-Option-F will send terminal into full screen in OS X Lion (or most any other app for that matter). You can also use the double-arrow button in the top right corner of an application’s title bar to make it full screen.
Command-Option-F (or switching to another app or Window that isn’t full screen) will end your full screen session. For any app, you can have one window that is full screen and others that aren’t full screen. Mission Control then shows all the full screen apps at the top of the screen and those that aren’t full screen towards the bottom. I thought I really needed multiple Terminal windows, but using the screen I haven’t found that I really notice not having two windows. And I have been trying hard to multi-task less in life. Seems like Apple supports such a change in workflow…
krypted July 22nd, 2011
DeployStudio has the ability to rename volumes as part of a standard workflow. These are typically set to something like “Macintosh HD” (the default) or “Computer Lab” or something like that. But what if you wanted to name the volume something unique to a given computer, which makes it easier to keep track with what you are doing across a number of servers? You could create a workflow for each computer and change the hard drive name for each to something unique; but that would be tedious and pollute your list of workflows, likely resulting in accidentally running the wrong workflow at times. Instead, you could look at a really simple script in most cases (according to how complicated your logic for assigning names would be).
To rename a volume, you can use the diskutil command along with the rename option. You would then list the existing name followed by the new name that you’d like that volume to have. In the case of DeployStudio the initial name of your boot volume might be “Macintosh HD” and to change the name to something like “Computer Lab” you would then use a command like:
diskutil rename Macintosh HD Computer Lab
It might then be logical to use a host name to rename a computer. Therefore, we could replace Computer Lab with the hostname command like so:
diskutil rename Macintosh HD `hostname`
However, this ends up showing the fully qualified name. Therefore, we could replace hostname with an scutil query for the ComputerName:
diskutil rename Macintosh HD `scutil –get ComputerName`
This would result in the name without all the .local, etc. But if you ran this as part of a DeployStudio workflow, you would end up calling the hard drive for all of your machines localhost. This is because the hostname or ComputerName will be queried from the DeployStudio set that you are booted to for running the DeployStudio Runtime. Luckily, DeployStudio has a number of variables that it can use in scripts. One of them is DS_HOSTNAME, which pulls the ComputerName being applied to the system at imaging. This means that if we were to rename the hard drive of the computer from Macintosh HD to the DS_HOSTNAME, you could use the following script:
diskutil rename /Volumes/Macintosh HD $DS_HOSTNAME
Now, one might think to oneself, couldn’t I just put $DS_HOSTNAME in the field for renaming the hard drive (part of a workflow). I tried it a number of different ways and couldn’t get it to work (in parenthesis, quoted out different kinds of ways, in different types of brackets and combinations of the above). If anyone knows of a way to use a variable in a GUI field within DeployStudio, let me know (I am guessing it can be done).
krypted June 12th, 2010
In Snow Leopard Server, Apple has introduced a whole new way to make Podcast workflows. It’s now simple to use, but still with amazing and powerful new automations that give Podcast Producer admins the ability to configure a host of new options quickly and easily. To get started, first setup Podcast Producer. Then, fire up Podcast Composer and go through 7 quick steps. First, provide a default name, author name and title for your workflow, then click on step 2.
In step two you’re going to configure the source of the video and audio. For each of the three options, Single Source, Dual Source and Montage, you’ll have an i to obtain more information about the source and configure settings more granularly. Single Source will perform much of the same functionality as Podcast Composer 1, you can select audio, video or Screen Recording (aka – screen capture). There’s a nice new feature for Automatic chapter generation for longer videos now, as well. Dual Source will allow users to use Keynote along with the video being captured, one of the coolest aspects of Podcast Composer 2 by far. You can select how the Keynote will interact with the video using some transitions familiar to users of both Keynote and iMovie. Finally, you can select Montage, which will use QuickLook to transition between various movies, images, documents (Word, Pages, PDF) and presentations (PowerPoint & Keynote) – if QuickLook can interpret it then you can drop them in.
When you’ve defined your source, let’s move on to Step 3, a very basic editorial workflow going from left to right on the screen, again using the information overlay (when you mouse over an item) to first define an Introduction movie, then a title sequence and effects for the title (which is user defined using your defaults), then the watermark (which you can now place anywhere on the screen, control the opacity for and place a bar along the bottom with information from your title bar and finally you define the exit credits. For all of these Apple has provided some stock footage but you can also define your own as well.
In step 4, define the output format (or formats as you can output a number of different clips if you so choose). Here, you can set the video and audio codecs that you would like to use. You don’t actually usually need to change anything in this step once it has been predefined in the workflow on the server.
In Step 5, choose where the recordings are to end up. Using this is really nice as you can simultaneously send your new podcast to a wiki, a Final Cut Server and a workflow-defined directory. If sending to a directory or a Final Cut Server then you have the option to perform further automations against the file.
In Step 6, choose who to notify (if anyone) about the new podcast.
Step 7 is to deploy the podcast workflow to your server. Simply click Save to output a file or Deploy to actually add that workflow to a Podcast Producer server (plug in host name, user name and password and hit save). Now, when users go to use Podcast Capture they’ll be able to use the new workflow!
Podcast Composer is a great start to allowing systems administrators to take more use of Podcast Producer 2 and all its new features without having to go out and learn complex ruby programming. I hope you enjoy it as much as I clearly have been.
krypted August 28th, 2009
When using Podcast Producer, the Podcast Capture client application will ask each user for a username and password. Armed with the authentication credentials. Once a podcast has been captured then the user will be provided with a list of workflows that they have access to. But where are these configured? They can be added and removed from Server Admin. And each can have a user, users, a group or groups that have access to use them. By limiting access to each workflow, based on the Workflow ACL, you can then limit who can access to different blogs, who can use various automations and even who can publish to an iTunes U account, or a different third party service if you’ve scripting against a given API.
In order to set these Workflow ACLs, open Server Admin and choose the Podcast Producer entry in the Server Admin sidebar, from the appropriate server. Then click on the workflow you would like to limit access to. By default, all users have access to all workflows. Click on the Allow Access to…for the following users and groups radio button and then click on the plus sign (+). Then from the floating list of users and groups, choose the object you would like to grant access to and then drag it into the list. Then click on the Save button and you will save your changes.
krypted August 21st, 2009
Posted In: Mac OS X Server
Once you have been using DeployStudio for a time, you’ll invariably end up creating a new master image. This is a hot topic this summer, given that Apple will be releasing Mac OS X 10.6 later this year and many people integrating DeployStudio want to make sure that they can manage the solution themselves during the subsequent updates. Provided you have been leveraging all of the best in package based imaging this might be a relatively small file, or if you are using a monolithic image for distribution it might be a fairly large file. Either way, DeployStudio makes it fairly straight forward to create a new master image. To do so, first get your imaging station ready using similar techniques to how you have created your master images (known in DeployStudio as Masters) in the past. Then follow these straight forward instructions:
krypted August 7th, 2009