Just 3 days after publishing this blog post GitHub made a new blog post:
To make it easier to find the pull requests that need your attention, you can now filter by review status from your repository pull request index.
I have tried this out and it’s great! Like most everything else on GitHub it’s very intuitive and simple to use. I won’t steal their thunder and describe it all here. So go check out the blog post for yourself and read up on the details (screenshots included!).
Continue reading if you’re still interested in incorporating this kind of filtering and labeling into your Gmail account.
I’ve been looking for a way to filter my GitHub Pull Request lists under the condition that a review is requested of me. The online docs didn’t show any filter options for this, so I checked out the @GitHubHelp twitter account. The answer was there on the front page — they don’t support filtering PRs by
@zaghnaboot Adding a filter for reviewers is definitely on our radar, though I don’t have a specific timeline to share. –SJ
— GitHub Support (@GitHubHelp) January 19, 2017
So what is one to do? I’m using Gmail so I began considering what filter options were available to me there. My objectives were to clearly label and highlight:
Interested in knowing more? Read on after the break for all the setup details.
Have you ever had a sub-select where you really needed to reference a value in the outer query? I know I have! The naive way would be to run the outer query and then loop over the results running the inner query on each one. Luckily, there’s a better way. The Correlated subquery. Check it out! The example given is
SELECT employee_number, name FROM employees AS Bob WHERE salary > ( SELECT AVG(salary) FROM employees WHERE department = Bob.department);
See how the sub-select references the outer query? It’s SQL magic.
bitmath is a Python module I wrote which simplifies many facets of interacting with file sizes in various units as python objects. A few weeks ago version 1.3.1 was released with a few small updates.
This new function accepts inputs using non-standard prefix units such as single-letter, or mis-capitalized units. For example,
parse_string will not accept a short unit like ‘100k‘, whereas
parse_string_unsafe will gladly accept it:
Several broken, moved, or redirecting links have been fixed. Wording and examples are more consistent. The documentation also lands correctly when installed via package.
bitmath-1.3.1 is available through several installation channels:
Ubuntu builds have not been prepared yet due to issues I’ve been having with Launchpad and new package versions.
bitmath is a Python module I wrote for working with file size units (ex:
64kB) as objects. You can use them just like you would use regular numbers in python. It’s full of other functionality as well. Objects have native ‘convert to $unit‘ methods, support native arithmetic, are sortable, and include a ‘best human readable prefix’ method.
Since March 2014, bitmath had only been available via PyPi and Fedora/EPEL repositories. Now, as of July 2nd 2016, bitmath is natively available to Ubuntu users by means of a new Personal Package Archive (PPA) hosting bitmath builds for Xenial, Wily, Vivid, Trusty, and Precise.
Ubuntu users can install bitmath in the following way:
I’m very excited (and proud) to announce that on March 3rd, 2016 I reached a long-term goal I set for myself 3½ years ago, by self-publishing my first book, The Linux Sysadmin’s Guide to Virtual Disks. The book is published under my new brand, Scribe’s Guides.
The first edition of The Virtual Disk Guide has been a long time coming. Nearly 7 years of on-and-off writing have gone into it. I’m relieved to have made it this far.
I view the book as the definitive reference guide for virtual disk related activities — clear, concise, accurate, and approachable to readers of all skill levels— but that’s just my opinion. You can decide that for yourself.
The book is quite thoroughly cited and annotated with nearly 100 individual footnotes and references to additional learning resources. The book weighs in at around 80 pages, 7 chapters, and two technical appendices. Here’s the byline from the scribesguides.com website:
The Linux Sysadmin’s Guide to Virtual Disks demonstrates the core concepts of virtual disk management. Real-world problems are covered in the book’s “Cookbook” section. Other topics include: helper utilities, disk formats, troubleshooting tips, performance considerations, and comprehensive appendices.
Or do both! Say “thanks!” by purchasing a copy, and then enjoy the latest builds online forever, for free!
 – The original first edition text is also available for free in PDF and HTML formats and is identical to the print copy
The official publishing of The Virtual Disk Guide does not change anything about it’s openness or your freedom to remix it however you wish. The book is still freely licensed under the Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0).
All of the source material used to build the book’s body material and cover images are still free and open source, covered under the same license. All digital media displayed in the book, such as figures and the cover art, was created using free/open source software. Each media item was created and saved in digital formats unencumbered by patents.
As ever, if you identify errors in the book or have thought of a way to improve it, please open a ticket on the GitHub issue tracker. If you’ve read a copy of the book already and would like to contribute a review or statement, feel free to reach out to me. Find my email in a github commit, or look at my other contact methods under the author highlight panel on scribesguides.com.
The experience of writing and publishing this book has taught me much, and it’s time to spread that information. Check back soon for a follow-up post I’m writing which covers more of the technical side of self-publishing. Specifically, self-publishing a DocBook 5 document at the on-demand printing website lulu.com.
Let me be explicitly clear, this is not a promotion for lulu.com.
Rather, the post will review some of the technical challenges I encountered (old examples: #1, #2, #3) during the publishing process, including challenges specific to Lulu. Such as, how I customized the PDF output from dblatex to look more personal and less generically academic, why I had to order three proof copies of the book before the cover matter printed in decent quality, and how to adjust your inner and outer page margins so there’s a reasonable amount of whitespace between the spine/binding and the body text.
I have a feeling that by the time I’m done with the blog posts I’m going to have written another book of documentation about how I wrote a book of documentation