(feat) TSLint warnings

January 10, 2017 | By Brian | No Comments | Filed in: opensource, tslint.

A few months ago, at the office, I was lamenting the fact that TSLint doesn’t have the ability to WARN of problems, therefore any new rules that get introduced will break the build. We have a gigantic project and have had a lot of success slowly implementing ESLint rules thanks to being able to give teams time to adhere to the new rules by setting them to WARN instead of ERROR. Once all the warnings are gone from the build we switch it ERROR and move onto the next rule.

I found two issues (#629 and #345on github and took a shot at implementing one of the suggested ways to allow for setting the “rule level”. At first I went a little crazy and renamed RuleError to RuleViolation which resulted in hundreds of files being changed. After a little feedback, I reverted that and added a simple RuleLevel that is attached to each Rule. I haven’t gotten around to writing tests for it, which is probably why it hasn’t had much attention, but I found the tests a little complicated and I need a solid block of time to get in there and make my changes. It’s also a bit weird because the TSLint project uses TSLint to lint itself. So, while backwards compatibility is very important, it’s a little odd trying to use the new stuff in HEAD while the scripts use the version (master) installed by package.json when running some of the tests.

I’m going to start pushing to get this pull request in as it’ll help my team adopt better and more consistent styling of our TypeScript. We have tons of Javascript being converted over to TypeScript and in the process losing our ESLint rules, so this is a high priority before we get too far off the rails.

Jewelbots Bzzzz

January 9, 2017 | By Brian | No Comments | Filed in: jewelbots.

So excited to see stuff moving quickly with Jewelbots! Literally 5 days after I made my pull request to extend the functionality of the Buzzer, it becomes available in the latest firmware!

http://alpha.jewelbots.com/t/arduino-library-update-6-different-buzzer-lengths-to-program/290

It’s not my code, but it is my suggestion, so I’m calling it a win!

Thanks ScottD! You rock!

Hello Jewelbots

January 5, 2017 | By Brian | No Comments | Filed in: jewelbots.

Being an early backer of the Kickstarter for the Jewelbots project, I was excited to finally give one to my daughter for Christmas. She’s poked at it a bit and made some cool color patters, but hasn’t fully jumped in. I think once the app and bluetooth connectivity arrive, she’ll get more into it. I am definitely more excited about it than she is, and I’m going to help get her there.

To that end, I’ve jumped into the forums to see if I could provide any feedback or assistance to those having issues. I found a request to provide the ability to use the Buzz function for an arbitrary amount of time. Currently only short_buzz() and long_buzz() are provided. I was able to quickly get something working and made a pull request to add it to the library. Special thanks to @glennblock and @noopkat for providing useful instructions on setting up the environment. It’s a constant work-in-progress, but this early on, it’s fun to hack-it-until-it-works. I am not in love with writing code in the Arduino editor so, I am going to see if I can get the compile/upload to work from something a little more friendly, like VSCode.

I’m all in on Jewelbots and hope to help make it a fun experience that encourages more daughters to get into coding.

AngularJS – Create and resolve promises in one line

April 3, 2015 | By Brian | 3 Comments | Filed in: angular.

So much of my test code had the same 3 lines in it to create a promise, and immediately resolve it. Ya know, creating stub promises so your tests don’t cross too many boundaries.

Create and resolve() a promise

  var deferred = $q.defer();
  deferred.resolve('This is the old way');
  return deferred.promise;

Replace it in one line!

  return $q.when('This is the new way');

Same for reject()

  var deferred = $q.defer();
  deferred.reject('This is the old way');
  return deferred.promise;

Replace it in one line!

  return $q.reject('This is the new way');

Notes

Yes it’s strange that to resolve you use .when(). I think this is just a quirk of AngularJS and will be changed in Angular 2 since ES6 supports similar (called .reject & .resolve) and it would be not smart to continue to do something different.

This is what I do

April 2, 2015 | By Brian | No Comments | Filed in: work.

Lotsa people can write code. I have a ton of respect for those that take the time to make it so incredibly clear it requires no explanation. I prefer descriptive names over comments. No one writes it beautifully the first time, every time. That’s why just “getting it to work” is never good enough. I am a software gardener, and I really enjoy it.

To that end, I thought this example of a recent refactor would be a good example to share. This actually help us fix a bug which turned out to be the fact that the unit tests was passing in a number for expectedLogoutTime, while the actual code was passing in a Date object. (Hence why I changed the variable name to expectedLogoutDate.)

Before

After