For some time, I needed a way to use caffeinate on Windows. If you are coming from macOS, you know how useful this utility can be when you want to keep the computer awake for some definite or indefinite time. So, following the engineer mindset, I decided to build my own, starting with a PowerShell script.
Right before the end of the year, I wrote about my updated approach to recording Nest video streams without having to worry about the Nest Aware subscription by reading from the video stream directly with the help of a .NET-based application I wrote, called FoggyCam.
Sometimes, you code for the sake of coding, and build something that is just fun. Back in June, my good friend Dan Fernandez came up with the idea of a website that can create Zoom meeting screenshots that place people in the company of celebrities, animals, or the Brady Bunch. That is, we’re not cool enough to actually hang out with said celebrities, but we can at least pretend that we chat with them over Zoom, to the surprise of our friends and family.
TL;DR: Check the source code out on GitHub for the project. It’s a demonstration of how you can use simple components to build awesome tools. That’s right, you don’t need Kubernetes for this! Table of contents Introduction The basics Ingress Data store Rendering layer Building the tools SQLite database Ingress script Analysis notebook Conclusion Introduction I’m one of those people that needs data around the things that I do - there is just something fun about being able to quantify and analyze things.
Yes, you read that right - my good friend Courtny and I launched a podcast, dubbed “The Work Item”, where we talk about everything that comes to mind in the product development and design space. We even have a mascot, named “Peppy the Post-It” (Courtny is the creative mastermind behind the art and the mascot name, by the way). Two episodes of this podcast are already out - the first one being on remote work (check it out on YouTube), and the second covering our career paths (also on YouTube).
Back on January 22, 2010, I started this blog - time sure flies when you are having fun! I didn’t even join college back then, and I already wanted to share the little knowledge and tips I had with the world. Ubuntu Karmic Koala was recently released, and I was fiddling with it overwriting my MBR, ruining my n-th Windows 7 installation. Back then, my dream was to one day work at Microsoft - a pretty far shot from someone coming from the part of the world I’m from.
Whenever we talk about documentation infrastructure, one of the most common pieces of feedback I hear from developers is that it’s too complicated to set up. There is just too much configuration, fiddling around and trying to make sure that the output is produced in way that is expected. That’s why back in June I set out to build a documentation CLI that allows one to produce docs with one liners.
You probably heard (or read) a post I wrote back in July about how we built docs.microsoft.com/samples - I talked about some of the foundational elements and the process which we followed to build the site. Now that we’re a couple of months in, I thought I would take a step back and write about some of the lessons learned about shipping the new site, in the hopes that this will be helpful to others who will work on projects of similar scale!
One of the biggest projects I’ve had the honor of being a part of has shipped a couple of days ago - docs.microsoft.com/samples. If you haven’t read the announcement blog post, I recommend you start there. Table of contents Inception Looking back First steps Improving the experience Published pages Automating releases Stack Conclusion Inception When we started working more in-depth on developer experiences, we realized that there are too many disjoint pages out there that provide an aggregation of code samples (and we ship thousands of samples that span hundreds of teams).
When building documentation for your product, you will often encounter situations where you need to mix and match a bunch of content that comes from different sources. It becomes a bit more complex when you need to start dealing with different platforms, e.g. documenting APIs for Python, .NET and Java all in one place. We do all that and more on docs.microsoft.com, where we host documentation that is both hand-written and generated automatically from code - DocFX is a very powerful and versatile system that allows you to do that with the help of pre-defined contracts for structured and unstructured content.
I love infrastructure and anything that has to do with it. That is - I love tinkering with different services and see what I can do to make them play nice with each other. I also like being efficient with what and how I deploy, and recently something dawned on my - I am spending way too much money on hosting my personal blog, that is 90% text. A recent analysis brought me to the number: 30$/mo.
For some time, at docs.microsoft.com, we’ve been using a non-standard way to document Java APIs. For example, if you take a look at this page, you will notice that it’s a regular API document. Behind the scenes, it was built with the help of Doxygen (generates structured docs from Java code), code2yaml (transforms Doxygen output into YAML) and DocFX (transforms YAML into static HTML). As we started documenting more APIs from across the company, we’ve encountered an interesting problem - Doxygen, while a versatile tool, relies on a set of conventions that are very much specific to its own stack and are less common in the Java developer community.
At GitHub Universe 2018, the team announced a new an exciting capability of the platform - GitHub Actions. At its core, this allows you to run "micro-CI" (or not so micro) within the repository itself. The benefit is two-fold: you can still plug in to other CI services, and you can also segment the workflow directly from the repository (there are some pretty interesting workflows out there already).
Yet another one of those times where people kept asking about something on Twitter, and I thought that it would be easier to write a blog post explaining the inner workings of things instead of responding in 280 characters. This time, this relates to "How can I build my own little docs.microsoft.com", so let's tackle the problem head-on.
Thought I’d start a series of videos talking about documentation and anything related to it.
This weekend I’ve spent some time to rework foggycam, the open-source tool to record Nest camera footage locally and to the cloud.
Last weekend I hacked together a solution that allows Nest stream capture locally. This weekend I got a chance to improve it a bit and make the entire solution cloud-ready.
We recently got a Nest cam, and we absolutely love the capabilities it brings to our home. One of the staples of the camera was the capability to record footage and then replay it later. The problem with that is we needed to pay for a subscription, and in my humble opinion, it's a bit pricey.
I previously talked about connecting to Instagram without the browser as part of a little hobby project I am working on. Another component of this project involves tracking the popularity of individual hashtags on Instagram, and how those grow over time. There are two approaches that I will describe here, each with its own merits, that can solve the problem. NOTE: This is a just-for-fun project - no private information is collected, or shared through it.
For one of the hobby projects, that I am working on, I thought I would leverage the Instagram API. It deals with an automation scenario, so the choice was obvious - I can put together a Python script that runs at scheduled intervals. Lucky for me, I’ve also learned that there is already a Python library that can help me access the API - it is archived and no longer maintained, but should at least give me some leverage over what I wanted to do.
Last week I thought I would sit down and learn how to write a Visual Studio Code extension - what better way is there to test the documentation your company ships and give yourself the best holiday present of the year? (photo by monicore) I will start this by saying right away how easy it is to work on the extension across two platforms - part of it was written on a Windows machine, and another part of a mac.
Today, we are once again talking about builds, and pushing for more automation in your software creation process. Before we get started, make sure that you have the following pre-requisites handy: A Visual Studio Team Services account. Those are free. An Azure account. Those can be free for trial (1). Installed Docker. Installed Azure CLI. Pretty much all of the code and descriptions described below can be followed on macOS, Windows or Linux, as most of them will be done within the web interface, through your favorite web browser.
I am a big fan of doing a lot of the monotonous automation work through Continuous Integration (CI). Specifically, I work a lot with defining workflows for documenting managed (.NET-based) API reference documentation. In the process, we leverage several tools, as you can read from one of my previous posts. The reality of software is, however, that it changes. New updates are pushed, new NuGet packages are released, and with that, there is a very high probability that the documentation changed as well.
If you read one of the latest Ars Technica pieces about how Microsoft renewed its strategy on embracing developers across the board, you might've stumbled across this little tidbit about code sample testing.
If you are following the news around our new technical documentation experience, you probably know that last week we revamped our managed reference experience and launched the .NET API Browser. In today’s post, I thought I would go into the nitty-gritty of the process and talk about how exactly we generate reference documentation for .NET Framework and related managed SDKs.
With the release of Outlook Groups, I got a lot of questions regarding the possibility of conversion of existing distribution groups to the new model. Instead of having users manually go through the process, I wrote a sample that demonstrates how it’s done with the help of EWS and Active Directory APIs. So how do you set it up?
At this point in time, Beem Plus has established itself as the de-facto DI.FM client for Windows Phone, although unofficial. With more than 45,000 downloads all over the world, I feel like this project is filling its niche pretty well.
I am proud to announce today, that one of my largest Windows Phone projects – Beem, is now open-source, in an effort to improve the product and to facilitate community contributions (there were many requests to add features – now devs can easily chime in).
You can download the Coding4Fun Toolkit source code. Once downloaded, go to Experimental > FileExplorer. The sample project carries an alpha implementation of the control, and I would love to get your feedback on it - let me know what you want to see become a part of it.
In a race to optimize everything, developers often go to extremes to build software that performs routine tasks. MissionControl is a system that allows users to program a control center that stores interfaces with attached hardware sensors, allowing the users to control any other devices that can be activated via the underlying protocol.
With the release of Windows Phone 8, a few new developer API endpoints were made available that allow third-party applications to change the device lockscreen image. In this article, I am establishing the infrastructure and building a mobile application that provides the ability to choose from a number of dynamic image sets, from which images can be selected and then cycled as lockscreen wallpapers.
With the full tutorial series and the PDF eBook, it would only be logical that the next step in the FallFury story would be releasing the game in the Windows Store. Today, I am happy to announce that my first big game development project successfully passed certification and is now available in most of the locations worldwide in the Windows Store.
Almost a week ago, my FallFury series (building a hybrid Windows Store XAML/DirectX/C++ game) was released on Channel9. 12 articles and associated videos is a lot to go through, and you might not always have an active internet connection.
If you follow this blog, you probably know that I spent part of Summer of 2012 in Redmond, WA, working on the Channel9 Coding4Fun team. My project for that period was FallFury – a 2D game that was designed to demonstrate the capabilities of the Windows 8 (specifically, Windows Store) development platform when it comes to creating hybrid applications (C++/XAML/DirectX).
While working on Beem, I always relied on a static XML file to fetch me the list of available online radio streams. It’s a good way to keep the content dynamic, and when new stations are added, I do not have to re-submit the application for certification but rather just update the XML file.
For some situations, the controls that are out there are not enough. That is why I started working on my own control toolkit. As I work on my own applications and feel the need to implement a custom control, I will add it to the Windows Phone Control Kit collection.
A while ago we saw a demo from Microsoft that showed how it is possible to use Windows Phone to interact with a Kinect-powered game. During the Kinect Code Camp, right before the official release of the Kinect for Windows SDK beta, Adam Kinney, Rick Barazza, and I decided to work on a proof-of-concept project that would provide the same platform integration in a non-commercial development environment.
According to the leaderboards (I am the leader of Team Core, by the way), the ImagineCup judges liked my Internet Explorer 8 Award entry, so I am moving on to Round 2 of the competition.
Today when I opened my email client, I got two emails from SoftPedia and one from SoftSea. These were notifications that two of my projects were introduced in these software directories. To be specific, PerformanceTweet was published and verified on SoftPedia and SoftSea, and WeatherBar was published and verified on SoftPedia. This means that I can stick this logo to the project descriptions: This is definitely good news, since I didn’t apply for any of these and it is good to know that the work is recognized.
I decided to enter the CodeProject “Windows @ Work” article contest. The idea behind it is creating an application that is using some of the new features Windows 7 has introduced. Since I had some experience developing software that is using the new Windows 7 features (the taskbar and associated jumplists, to be specific), I thought that it would be a good idea to participate in this contest as well.