Using GIFs on Bug Reports

/

If you've been developing software for any length of time you've fixed a bug or two that someone has reported. Whether for a customer or a user within your organization, sometime's words of how something is fixed or how to duplicate an issue may not be enough.

Using screenshots is great to show if something is working, especially if it is something easily to show like a UI element working. However, to show that a series of steps is working with the end showing that the fix is there, I believe GIFs are a great way to include in your bug reports after a fix has been implemented.

But How Do I Make A GIF?

I primarily run a Mac, so I really love how easy Screenflow is for this. Sure it's primarily for screencasting, and I use it for that, too, but it's really easy to make GIFs with this.

Of course, there are free alternatives (before Screenflow I was using Recordit with good results) and they all are good to use in their own right. One thing I really like with Screenflow is that it is really easy to edit after recording your GIF.

Why Does Editing GIFs Matter?

The primary reason why I'd want to edit a GIF is to remove unneeded parts of what I was recording. The same thing you'd do with any video, remove any dead or time consuming parts. If you're recording a GIF to show that something is working after a fix is put in, you may have times where you're waiting for a process to execute in order to show the fix is working. Editing your GIF to remove the time it takes for the process to launch and load will reduce the length of the GIF as well as to make it smaller for uploading or viewing.

Another awesome reason I like using Screenflow for GIFs is that you can use all the advanced screencasting features Screenflow provides for you inside of your GIFs. For instance, I can zoom in on places I want to show in the GIF or highlight specific areas of the screen so the viewer can know what I want them to see.

Let's take a look at an example. I did a very quick recording of some F# using VS Code and running a selection in the FSI. Here's the GIF of that using Screenflow's editing tools.

Not the best edited example, but I hope it helps illustrate some of the things Screenflow can do to make GIFs that much better to include in bug reports.

There are a couple of things of note, though.

  • Screenflow allowed me to specifiy what area I wanted to be recorded. I just adjusted the preview window right before recording to the size I needed.
  • I did a small zoom to better show the FSI output.
  • I did a callout to show to viewers the specific output in FSI of the input I gave it.

I got Screenflow to start doing some screencasting, but since they've introduced GIF support I've been using it much more for caputuring GIFs for projects at work and uploading them to whatever bug tracker we're using (Jira, Visual Studio Team Services, GitHub) and, to me, it's been quite helpful. Often I've recorded a GIF and found something else I needed to work on for that issue before it should have been sent back as fixed.

Are Daily Status Meetings Still Needed?

/

I'm sure you're used to this scenario in your career by now: you start a new project and the manager instantly schedules daily standup meetings for everyone on the project to give their status. However, how many times has that meeting gone longer than the supposed no longer than 15 minutes? How many times has the discussion gone very off-topic taking even more of everyone's time? Quite a few times I'm sure.

I'm going to propose right now that I believe these mandatory daily meeting slots are no longer required for developing software using Agile.

It has long been said that meetings are usually a waste of everyone's time that has to be in them. If you look at the origins of these daily meetings, you will note that it was first brought up in the late 80s and into the 90s. It was then further developed in the early 2000s. At that point I can understand the use of them. Everybody was in the same office and there weren't any tools at that time that they can use to reduce or eliminate thier time in these meetings.

A lot of my thoughts in this post are going to resonate with a post Zach Holman did a long while ago about asynchronous communication. A good reason to use this type of communication is that people aren't commiting a specific block of their time. They can be in the best state of their entire career for programming thoughts to flow, but then they get a notification from their calendar that they have a status meeting in 15 minutes. This will definitely take them out of their flow state, take a few minutes to figure out what they need/want to say in the status meeting, then go to it.

From my experience these meetings always last longer than their intented length. It is said that they should only take 5 to 15 minutes total, but of course they usually go longer than that. And they usually go longer due to random, off-topic discussions. Whether it's about something with the project that came up and can be totally done over email or something about what the local college football team did the night before.

If the team is entirely remote then things get a bit more complicated. I agree with most things Jason Fried and David Heinemeier Hansson suggest in their book, Remote: Office Not Required. Being remote should allow the employee the freedom to handle things at home at the time it happens. One example was that if you need to get groceries at 10am then you should be allowed to do that. Then you come back home and continue to work. Personally, if I need to take someone I care about to the doctor at that exact time, I shouldn't have to worry about whether or not I need to make it to a status meeting.

Communication Tools

I explained the reasons why it isn't the best reason to continue holding daily status meetings, but what can be done as an alternative? Communication tools are getting much better as time goes back. The company I currently work for has adopted Slack. While we can make a channel for each project that we have and say our status there, there are also bots that can be integrated to do this for us.

Email is still used widely for communication. However, in these times of instant gratification, folks tend to think that we should instantly get a response after sending an email. That's definitely not the case as email is still a tool of asynchronous communication. People will respond when they can to email. In fact, if people are following the advice from the The 4-Hour Workweek book, then they will only check email two or three times a day.

Again, communication tools, especially for remote workers, are getting much better as time goes by. Slack may get beat by another tool or company that comes alone in the future. Join.me, Zoom, or Screenhero are great tools for screensharing or pairing. There are even sites that can help you find coding help instantly if you don't mind paying for it.

With the current state of tools these days and the growth of remote workers, having daily status meetings should be going as a thing of the past. Hindering employees flow state and taking their precious, and often expensive, time are too high of a price to pay for software projects. When daily statuses can be just a few minutes of typing at the leisure of the person giving the status, I really believe that having mandatory meeting times are a thing of the past.

Using Draw.IO for Mockups

/

I'm definitely not a designer. However, there are times a developer has to do their best to get a new website out for a client and that means doing the initial design for it.

As I was thinking through this I figured doing wireframe mockups would be best. But what tool to use for it? There are some tools for this, of course. Since I didn't need anything real fancy I decided to give Draw.io a try. Believe it or not, you can do some pretty decent wireframes with it. Here's a quick way to get started with it.

Enabling Mockups

You could use Draw.io's default shapes to create mockups, but they do include a lot of very helpful shapes and elements as well. These aren't on by default, however, so they must be enabled in order to use them.

First go to the More Shapes section below the elements section.

In this popup you can then select to add the Markup section.

Using Mockups

After the mockups are enabled, we can begin using them. I'll create a simple web page in this post to demonstrate a few items that may be helpful.

One of the mockup sections is the Mockup Containers. This has a mockup of a web page that we will use. Either drag and drop it to the canvas or single click on it to add it.

Within here we can create our page elements. How about we add a nav bar to the top?

Here we did a drag and drop on the Menu bar element inside the Mockup Forms section. It comes with default text values but they can be changed by double-clicking inside of each of the single section elements to change the text.

Next we'll just add a simple Welcome text to the middle of the page. Draw.io is really good at giving you feedback on where you're positioning your elements. Here's a GIF to help illustrate.

The examples above are only just a small couple of things you can do with Draw.io. It is very good at quickly getting something going with simple mockups. While it's not a replacement for tools such as Sketch it serves as a good tool to get ideas out for others to see in a visual way.

It was my first try at doing mockups and a design for a website. While designing the site wasn't as hard as I thought it would be I would need a lot of practice to imagine something really creative. The design I did was for a simple administration application that only a few people will be using. I may eventually step into the world of Sketch and learn how to use it for future mockups and wireframes. If you're like me an very new to this world, Draw.io is a good alternative to get something going quick, easy, and free.

Xamarin Evolve 2016 Recap

/

I'm currently writing this at the Orlando airport waiting for my flight to head home back to South Carolina. Normally I couldn't wait to head back home after an event to relax and to just, well, be home. However, I'm a bit sad that I have to leave. I met some awesome folks, both Xamarin employees and other attendees. I have an absolute blast helping to give training for Xamarin University. And I got to experience Wizarding World and Jurassic Park at Universal.

I'll split this recap up into two sections, training and the actual conference, since they were two different event. Yet I couldn't imagine a better experience without doing both.

Training

At each Xamarin Evolve they include a two day bootcamp style training. It's basically a set of Xamarin University classes in two full days. It can be pretty intense, but you really get a lot out of it.

A colleague and I were asked to become adjunct trainers to help out with some of this training. When I was asked to join I first thought, "Crap, this is going to be really scary being up in front of folks for two full days!". But then I remembered that the best way to grow is to get out of your comfort zone. So I accepted.

During the time up until the actual training, I learned a lot about how much preparing and practicing really does matter even though it's the last thing I want to do for it. It was also around that time that I heard a Hidden Brain episode on grit. The lesson learned there is that using your grit to do things is the least fun experience, but it helps reap in the rewards once it's all done that much more. I then took preparing more seriously. I even took a hiatus from reading books! That's something that hardly ever happens.

The first day of training comes and I don't feel as nervous as I did during the practice sessions. My colleague did the introductions and welcome session. Then I was up for my first session to introduce Xamarin Forms. I then ended the day finishing half of the last session on local data. The next day I resumed the local data talk and went straight into web services, while my colleague finished out the rest of the day.

My absolute favorite part of the training was interacting with the students one-on-one and helping them when they had questions or issues during the labs. I definitely want to do this again and it's great inspiration to give more talks. I'm already thinking of what I can present on next and start preparing the materials for that.

Conference

The conference itself was nothing short of amazing! Tons of great sessions that are already posted online (thank you, Microsoft!). I learned a great deal just by attending the ones that I did and will definitely take that home with me for future projects and learning.

Here are a few sessions I attended:

  • If You Build It: Making Apps for Humans - A wonderful presentation that showcases several interviews the presenter had with, not only some other developers, but with people you would encounter on the street with other careers besides tech. Honestly, this made me want to attempt something similar in my home town.
  • Becoming a XAML Master - I've done XAML in Xamarin Forms for around a year and half now and have come to really enjoy using it for building up my UI. This session covers a few extra tricks I can incorporate to utilize the power of XAML instead of having to write out extra code.
  • Enhancing Your Mobile Application with Machine Learning - I've been interested in data science and machine learning for a while now and this was the perfect session to get me started on the path of learning more of it. Great demos in this one!
  • Mobile Apps in F# - Of course I have to go to an F# session! This one really drives examples of why you should try F# and some demos of using it in Xamarin applications. The async and MailboxProcessor stuff here is really digestible!

Another one of the highlights of the conference was definitely going to Universal Wednesday night for Wizarding World and Jurassic Park. Rode on a couple of rides, finally got to try some butter beer, and just hung out with awesome folks.

Something that surprised me was the amount of F# fans that were also at the conference. I met several of them there and had tons of great discussions on the language itself and the community that surrounds it.

An interesting thing they do at Evolve is they have a section called the Darwin Lounge. This includes mini-hacks that you can do and win prizes and play with some of the awesome things they have also created

All this really sums up to is to just go to Xamarin Evolve every chance you get! It was and still is the best conference experience I've ever had!

And obligatory monkey photo...

More Medium Shenanigans

/

Once again I've been playing around (and definitely reading) with Medium. Honestly, this is probably one of the best mediums for writing, especially how much tied it is to Twitter and Facebook for very easy sharing. I figured I'd write a few articles there to share around that community.

If interested, y'all can follow me on Medium. I do more recommending and writing responses to other articles than creating my own.

Book Review: Elon Musk Biography

/

I've done a few book reviews in the past here, but I admit I've been slacking a bit. Not on the reading, though. I've actually been reading even more. I've been slacking a lot in writing about my thoughts and notes on each of the books. It's time to change that.

 

 

For those who are a bit out of the loop and doesn't know who Elon Musk is, he's the CEO of both SpaceX and Tesla as well as a chairman of SolarCity. From those credentials alone you can definitely tell that this guy knows what he's doing! One thing I like to tell people when describing Elon Musk is that I do believe he's the biggest innovator of our generation. This book, Elon Musk: Tesla, SpaceX, and the Quest for a Fantastic Future, will definitely describe how that statement is true.

From the start you get a sense of Elon as he was as a young kid. The biggest thing to hit me was just how much he read at a young age. This is actually not very surprising as I've always heard that the best leaders and innovators are voracious readers. Of course, that's not the reason I like to read, but it is nice to know that you share this habit with people like Elon.

What is interesting is the story of Elon's earlier companies, Zip2 and X.Com. X.Com eventually did merge with PayPal and Elon was the largest shareholder in the company. These two companies gave Elon his first millions.

SpaceX

With the money from the previous companies, Elon started SpaceX. This was brought on by a life-long dream to go to Mars. The book details the innovations and early failures of the company that builds their own rockets right in the US.

The innovations being that all parts of the rocket were built in-house at the SpaceX factory which turns out to be much cheaper than buying them from other countries. They continue to innovate by building rockets that can be reused by coming back to earth and land by themselves.

They did have early failures when they tried to launch the first version of their Falcon rocket which almost brought the company into bankruptcy. Thankfully, they were able to get a successful launch and able to win a lot of bids from NASA to keep the company going.

Tesla

Tesla is definitely a company I've been following for a while. Ever since I got to test drive a Model S in Houston a year ago, I've been interested in them.

A bit of a detail of Elon and Tesla is that he's a co-founder because he was the first investor into the company. If he didn't do this, then the company would have gone bankrupt long ago and due to that, I would consider him a co-founder. With that said, Elon probably did do a lot for the company as its CEO. He helped get the initial Roadster out and had a lot of input into the Model S.

I'm definitely looking forward to what this company will bring, especially with them making their gigafactory that should help bring down the cost of the batteries and, overall, the cost of the car.

Conclusion

Overall, I thoroughly enjoyed this biography. I already thought Elon Musk is an interesting person and definitely someone I'd want to meet one day. This book gave a bit more insight into him as a CEO and innovator as well as the histories of SpaceX and Tesla.

I'm pretty sure there will be more to come from Elon and I'll be waiting anxiously for another book on the rest of Elon's innovative career.