Dashing widget to show widget count

We build a lot of Dashing widgets dynamically, and discard just as many (see clearing Dashing widgets). As a part of that, I like seeing how many widgets we currently have, since each dashboard only displays a small faction of our total widgets.

We have the following file in our jobs/ directory:


This goes through the widget list and updates a widget called widget_count with the total number, which can be displayed in a nice little number widget.

Delete a Dashing dashboard widget

Every once in a while it's nice to be able to remove a Dashing widget. Maybe the data's stale, or otherwise may have bad data. This is a short snip that can be added into another Dashing job. Obviously this sort of job isn't what you'd want, but it should give you the info enough to put this into your own solution.

Widgets using this data will still exist, but just not have that data to pull from. Forcing a refresh of the dashboard (if it's up constantly) can then have it re-poll for the non-existant data, causing the widgets to revert to their "no data" state.

Clear Dashing Widgets

There are a handful of ways of clearing old widget data from Dashing, but none are well documented. Here are a few options, all of which boil down to the line:


This can go in a few places, depending on when and how you want the history cleared. We are dynamically making and discarding tons of widgets, so regularly clearing out the stale data is useful for us.

The main options are:

Clear widgets when Dashing starts:

Find the file, and add the line before the "run Sinatra::Application" line.

Clear widgets on a schedule:

Make a new job file in the jobs/ folder and create a file that looks something like:

The above will clear the history every midnight. The '0 0 * * *' is the schedule, using the format for cron jobs.

The Dashing Dashboard

Experts in DevOps are always interested in new ways to communicate technological innovations to interested industries. For many companies, the dashboard, which should present essential information in an easy to read graphical user interface (GUI), instead becomes a headache and a hassle with utility and design competing for supremacy rather than working together in harmony. The Dashing dashboard works to solve these problems by providing data in a simple, elegant solution.

What is Dashing and How Does it Work?

Dashing is a Sinatra based framework, which is a bit like Ruby without the Rails. Dashing allows developers to utilize premade widgets or design their own with HTML, SCSS, and data bindings from batman.js depending on their individual needs. To get your data to your widgets, you create a widget id then pass in the data with jobs (by using rufus scheduler) or API (directly over HTTP). A drag and drop interface makes it easy to rearrange your widgets quickly and efficiently.

Why Should I Use Dashing as a Dashboard?

The simplicity of the interface allows developers to focus on personalization elements (such as matching the company's design and tailoring the specific information the widgets will display) rather than muddling through overly-complicated coding requirements. Dashing dashboards update in real-time to make sure your business is displaying the latest data. The Dashing frontend also displays in any browser so it stays adaptable to a wide variety of situations.

Dashing has been used for a variety of diverse situations due to its simplicity and adaptability. The Dashing widget challenge produced a gallery of exciting examples and possibilities for the dashboard's potential.

Keeping the Inbox Clear with Inbox Zero

How many of us in the working world can't say that we haven't had that moment when you look at your inbox and it tells you that there are one hundred unread emails waiting there for you? Most of us look at that number and quickly dismiss it as something that we will do later, but by doing so you might miss that one key email in the haystack which you needed to look at. So to remedy this, we can start picking up the Inbox Zero method of email organization, first promoted by 43 Folders.

This idea of keeping the inbox clear or almost clear by Merlin Mann has a few basic tasks that can make this a possibility, those few being:


If there is an email that is unnecessary say spam or information that isn't critical or a priority, then you can go ahead and delete it to make room for the more important emails and to prevent clutter.


If you have peers or subordinates or even superiors who might be able to answer an email better and more accurately than you, then don't be afraid to send it their way and ask them to take care of it so that it's A) Out of your hands and B) Getting done properly.


If you have an email in your inbox that you can look at and you know that a response wouldn't take you more than 3 minutes, then simply do It and get it out of the inbox. Send a response and then delete the email so that the dead clutter that it would leave behind is gone.


Some emails are going to take a bit more time and effort on your part than you can get done in a few minutes. If that is the case ten set aside the longer and more difficult emails to a folder that you will take care of at some point in the day when you have the time. Maybe set it so that you put a little time away to get the big emails done for an hour or do it at the end of each hour.

Get it Done

Probably the hardest part of course is putting all of this in action. Yes, it  will be tedious at first, but the gains are what makes it worth wild. There will be no more surfing through tides of emails to find that one special one you need. It's all a matter of taking the time to get it done. Be sure to set time away for yourself so that you can answer the big emails and do clutter maintenance often.

By putting all of these pieces into play, you can easily turn an inbox that would be flooded and confusing into an easy and streamlined railway for emails to come in and quickly leave or be stationed for later. It makes life easier and it makes getting the job done easier as well.

DevOps - "Sharing the Sandbox"

There is considerable debate concerning a standard definition of "DevOps". A hot topic in multiple industries, it appears that each organization may need to define the concept in terms of how it can be implemented in an industry-specific manner. Or better yet, it can be defined more optimally on a business-by-business basis.  Originally coined as a term to express a need for the developmental and operational sides of a business to collaborate more effectively together, it has instead come to mean different things for each organization that tries to incorporate it into business training and practice.

However, the thinking behind DevOps appears to be the same across all industries. In the simplest terms, the goal of DevOps is to help a business succeed from inception of ideas to fruition of finished product.  Implementation of DevOps strategy is a win-win situation for all departments of a business, from development all the way through to software product release or implementation.

That being the case, what are the basic principles of DevOps?  Surprisingly, it all boils down to what your mother taught you when she first put you in the sandbox with other kids on the playground.  Play nice, and share the sandbox.  Who knew Mom was such a forward-thinker? 

How can Mom's advice be applied to DevOps in the real world of tech?  There are several guiding principles which must be used to achieve the goals of DevOps. While an idea may begin to take shape in an IT department, input from the operations side of things must be taken into account for a seamless process to develop.  A reciprocal form of communication must be established for optimal results.  From a business practices standpoint, an organized pipeline of useful information must be put into place between departments to facilitate open and honest dialogue.

Feedback must be a strong lynchpin of this type of communication. While IT may be all about the tech side of the coin, and Operations may be all about implementation of IT's vision, neither side can reach full potential without the cooperation of the other.  Software developers make better decisions when operational knowledge is taken into account, and operations does better when applications knowledge is considered.  Cross-training between departments increases understanding and collaboration for the enterprise overall.  Feedback fuels innovation on both sides of the fence.  Or rather, in a perfect DevOps solution, there will be no fence at all.

Thus, the focus becomes not, "What will make this work for my department?", but rather, "How can we optimize the whole process, from start to finish, with cohesion and cooperation?"  The real focus will be on collaboration toward the common goal of making your business ready to seize opportunities in technology and advances in other fields with agility born from a spirit of commonality.  Such cooperation would make Mom proud, and will give your business a definite advantage over more compartmentalized enterprises.

Jamf computer renaming using JSS assigned user

We want to name our Macs based on the user that we assign them to. To create some uniqueness, we also append part of the MAC address of the computer, creating computer names like "mknowles-e256". We then use Jamf to bind to our Active Directory domain.

That's great, but before the computer is bound we don't have the username, and can't rely on the local username; there's no standard out there (for us) on what those user names may be.

We do, however, assign the computers to an appropriate username inside Jamf. We found that the scripts didn't always send this username down to the computer. Using the "$3" username parameter for scripts seemed to work only occasionally, and not in a way that made sense to us.

To get the username, a new script was born. With some ideas and help from Jamf support and some back and forth with Bill at work, we have something working. This method returns all the "user and location" information from the Jamf computer entry, though we currently are just using the assigned username.

Take the following couple of lines of script:

mkdir -p /tmp/jamf/

# get location data from jss
curl -sSk -H "Accept: application/xml" -u api:apipassword`system_profiler SPHardwareDataType | grep Serial | awk '{print $NF}'` > $XMLFILE

This gets the "user and location" section of the computer and saves it to the temp folder as an xml file. This in a script can then be used to get up-to-date info that can be parsed into, for us, the username and eventually the computer name we want the computer to have.

All it does is go to the Jamf server and pulls the data as a web page. It's not all that elegant, but it's been reliable.