I’m Lazy

Yes, I’m very lazy and proud of it. Most programmers out there will understand that. We’re among the laziest people you’ll ever meet. We’ll work hard and create a vast array of tools and scripts to aid us in tasks that we consider boring or repetitive, all so we don’t need to do extra work. Many of the repos at gskinner have a utils folder that’s full of scripts that serve one specific purpose. That’s a good thing. In daily programming, there are always repetitive tasks that crop up. Some are easy, some are just boring and time-consuming. Here are a few tips to help you also be lazy and save those precious seconds during your day.

When Should you Create Tools?

  • Is there a group of tasks that’s repetitive? Ex: everyday are you running the same X commands? Make a script to wrap them.
  • Is there a boring, but labor-intensive task that comes up every few weeks or months? Make a script for that. A good way to know when you should create a script for these tasks is, are you always having to remember those nit-picky details about how to do it? Or are there weird edge cases you know will be forgotten? A quick script will help isolate those dependencies for next time.
  • Is it a task that’s large and time-consuming? Examples could be data extraction or converting a folder full of files. Make a script for that. Sometimes if you know that one task will take you a few days (or more) to complete. Then, by all means, spend a few hours or even a day or 2 making that script that will save you time in the long run.
  • A “tool” doesn’t need to be a script. It could be a small, throwaway, RegExp expression. I don’t know how many times the “List” feature on https://regexr.com/ has saved me from hours of tedious data conversion tasks.

Focus on Functionality 

These tools don’t need to be perfect. They don’t need to be used by other projects or other people. Sure, if you make something that’s useful, then, by all means, consider making it more portable. But don’t waste time upfront with that extra work. It’s very tempting to over-architect your tool, but it may only be a script that’s only ever used in your project, or potentiality only runs once or twice. Your initial focus should be making it functional and don’t worry so much about error handling. Don’t worry about making the UI or cli interface perfect. Don’t worry about making the code clean. Do what’s fast, do what’s gonna get you to that point of running the script, so you can move past your boring task. You can always tweak or polish your script in the future. Or someone on your team will.

Organization 

Sometimes a tool turns into something more. Something that requires you to start adding command-line arguments or even UI. If you are in a JavaScript project, chances are you already have a package.json file.  And it’s super easy to add scripts to it. More on that here: https://docs.npmjs.com/cli/run-script. This helps centralize your tools, and makes them easy to discover, run, and self-document. For other projects just having a utils/ folder can be fine. Just remember to name your script something useful. runMe.sh is not useful. download-strings.sh gives some context to what will happen when you run this file. Don’t forget to add some docs. Use your repo’s README and add a one-liner to say what your script does, and any potential arguments or gotchas for running.

Stay Lazy!

Cinema 4D Lite vs Blender

I’ve been recently learning Cinema 4D Lite in my professional development time at gskinner and comparing it to Blender 2.8. After having spent time in both pieces of software, I wanted to share the pros and cons of using these 3D tools. So here is what I know you’ve all been waiting for: the C4D Lite vs. Blender Battle of 2020!

Battle of the Software!

Rotating bottle of hot sauce made in Cinema 4D Lite
Rotating bottle of hot sauce made in Blender

I couldn’t think of a better way to test two 3D packages than with a hot sauce bottle showdown. Using both C4D Lite and Blender, I tried to create the same scene to showcase the abilities of both.

Continue reading →

Flutter: Introducing StatsFl, an FPS monitor for Flutter

As we begin pushing Flutter to more platforms such as Desktop and Web, it is becoming increasingly important to quickly and easily measure performance of your application. While the built-in performance monitor gets the job done, it leaves a lot to be desired in terms of readability and flexibility.

As the old school Flash devs we are, we remember the days when virtually every Flash application around would use the hi-res-stats package by mrdoob (yes, that mrdoob). It was extremely helpful to catch performance issues, and make sure your application was smooth (which in those days, was a solid 24fps!).

Currently nothing like that exists in the Flutter community. To help fill this gap, we’ve created StatsFl! Available now on pub.dev: https://pub.dev/packages/statsfl

Continue reading →

Flutter: Create Custom App Themes

There is a lot to like about Flutter, but one area I’m sure no one loves, is taming the Material Theme system! With over 65(!) properties, some of which, like TextTheme, break out into 10 more sub-properties is enough to make you go crazy pretty quick.

Who wants to dive in?

Last week we looked at how you can easily implement TextStyling, and this week we’re going to dive into Color Themes. We’ll take a look at a technique that we use to implement custom app-specific themes, while still providing Material ThemeData to the core Flutter components.

Continue reading →

Flutter: Simplify your PageRoutes

One of the more verbose parts of Flutter is pushing new pages into the Navigator Stack, especially if you want to use something other than the standard Material or Cupertino Routes.

The standard recommendation from Flutter Docs, is to just build your PageRoutes inside your button handlers, and then pass them directly into Navigator from your views. Something like:

Navigator.of(context).push(MaterialPageRoute(builder: (c)=> MyPage()))

This works, but can end duplicated the same code all around your code base replicating the same transitions, violating the core tenant of DRY programming. Additionally if you’re using custom routes, then you’ll be forced to create additional widgets for each type, or worse, copy tons of boilerplate from view to view.

Continue reading →

Flutter: The new ‘animations’ package explained

The Flutter team recently dropped a great new transitions package, based on the new Material 2 design spec, the somewhat ambiguously-named: animations package.

SharedAxis Example

They are super cool to look at and appear to be highly performant. The only issue? The examples they’ve provided with the package are pretty hard to follow (coming in at close to 1500 lines!) and there’s no code snippets at all in the README.

But fear not! This package is actually extremely simple to use once you clear away the noise, and can see how it works.

Continue reading →

Flutter: sized_context – An easier way to access MediaQuery.size!

After sharing our simplified screen size detection example to reddit last week, we received a great suggestion from the community: the concept would work better as a set of extension methods.

The original thought was to add the methods to MediaQuery, which didn’t seem that appealing because it would still be quite verbose to access. Then we realized we could just use the build context directly, which turned out really nice! So nice, that we’ve gone ahead and created a package for it here: https://pub.dev/packages/sized_context.

Continue reading →