I’m currently a Principal Software Engineer and have been working at Bodybuilding.com for about 8 years now. In addition to normal development, I’m responsible for helping my team of client-side engineers, software engineers, and QA in whatever project we’re currently working on. I also have a helping hand in guiding the technology we use at Bodybuilding.com along with the other technical leaders.
Mac, but only slightly. There are some applications and utilities on my Mac that just aren’t there, or aren’t as good, on Linux. That being said, a good portion of my work is spent in the command line, so as long as it’s not Windows, I’m not super picky.
The mornings are fairly consistent, with a daily scrum to discuss what we’ve been working on and what’s coming up. After that, my day is spent in a combination of working with the other members of my team, meetings, and heads down with my headphones on getting some work done.
#1 - An IDE. Depending on what I’m working on, it’s either IntelliJ or Sublime Text. #2 - Slack. Getting push notifications on my phone when someone needs me and I’m not online is a huge help. #3 - Google Chrome as my preferred browser. #4 - Spotify. Music is important to my development mojo. #5 - Terminal.
alias yolo=‘git commit -am “Deal with it” && git push -f origin master’
Kidding.
Honestly, the best tip I can give is "stay in the flow”. It’s tough to get back in once it’s broken, so do everything you can to minimize distractions.
We’re currently in the process of migrating upwards of 28,000 articles to a new CMS system living in Amazon Web Services (AWS). Today, I continued on with the migration script to download every image from an article and upload it to S3. In addition, tweaking and fine-tuning the process to make sure the cutover is as seamless as possible to our readers.
Last year, we update the wrapper (header, footer, and sidebars) across our entire site. This was a HUGE project. Every technical team was involved in updating around 15 different Java and PHP applications, migrating our front-end code to use a new build system and AngularJS, site-wide feature enhancements like search and a new navigation, and countless other features. This was all completed in just a few months before the holidays. In all my years working at Bodybuilding.com, never have I seen collaboration between such a large group work as smoothly as it did.
The only one that comes to mind is the “poo-nami”. I think that one should be left up to the imagination.
You get to work on the coolest, most cutting edge products, with the coolest, most knowledge people around. There’s a lot to love about working at Bodybuilding.com.
Third-party apps are generally fine to leave open-ended, using the ^ or ~ shorthands. More often than not, we want the latest bug fix. But as we're developing our own interdependent apps, we need to lock down the version request. It's verbose, but in most cases the only way to restrict the version to a set tuple, while allowing pre-releases within that tuple, while also rejecting any version outside of that tuple, is:
>=x.y.z-0 <x.y.z+1 (where -0 is literal text and z+1 is one more than the number represented by z)>=x.y.z-tag.0 <x.y.z-tag.100>=1.2.3-0 <1.2.4. Note that we need to explicitly use the -0 part of the version; without it, Bower will only look for stable releases, and, in effect, we could have just said =1.2.3. With the -0, though, we gain several things:1.2.3-x version.1.2.4 and higher, pre-release or otherwise, ensuring that the team gets the version they're working on.1.2.3 release valid for that range and prefer it over the pre-releases, meaning the app that is requesting the version doesn't necessarily need to update its bower.json in order to release. Ideally, at release time, bower.json specifies exact version numbers, but if a version was missed then this notation won't break the desired behavior.>=1.2.4-0 <1.2.5, they will ensure that they don't accidentally pick up version 1.2.3 when it becomes an official release.
Note that you can try these with your own private Bower registry. Create a new git repo, register it with your Bower server, and then iterate over changes to the readme file, while releasing the various tags. Then you can test with bower info [your-bower-project]#[request version here].
>, <, and space characters – for example, bower info test-semver#\>=1.0.0-0\ \<1.0.1 – or else wrap the whole package#version part in quotes, like bower info "test-semver#>=1.0.0-0 <1.0.1". (For reference: how the command line uses spaces and angle brackets)0.0.00.0.10.0.2-00.0.2-10.0.2-20.0.20.0.3-00.0.3-10.0.30.0.4-00.0.4-10.0.5-00.0.5-1
Requested version
|
Resolved version
|
Notes
|
|---|---|---|
^0.0.0 or ~0.0.0 | 0.0.3 | Bower assumes you want the latest stable release. 0.0.4 and 0.0.5 exist only in pre-release versions, so 0.0.3 is resolved. |
>0.0.3 | 0.0.5-1 | Only pre-release versions are greater than 0.0.3 (because we aren't including 0.0.3 itself), so even though Bower would assume you want the latest stable version, there is no latest stable version in this case, and the latest pre-release is returned. |
~0.0.4 | 0.0.5-1 | Essentially the same as the above example. We want the latest patch greater than or equal to 0.0.4, and since there are no stable releases in that range, we get the latest pre-release. |
0.0.5 or =0.0.5 | none | Declaring a stable version with no range will not return any version if the stable version doesn't exist; Bower assumes you want the exact stable version requested and will not return the pre-release versions. |
1.0.0-alpha.01.0.0-alpha.11.0.0-beta.01.0.0-beta.11.0.1-foo.01.0.1-foo.11.0.1-bar.01.0.1-bar.11.0.1-z.01.0.1-z.11.0.1-a.01.0.1-a.1
Requested version
|
Resolved version
|
Notes
|
|---|---|---|
>=1.0.0-alpha.0 | 1.0.1-z.1 |
Apparently, Bower considers anything with a pre-release tag as simply a marker to get a pre-release. It considers the "latest" to be the highest in an alphabetically sorted list of tags. Therefore, pre-release
z is chosen. |
>=1.0.0-alpha.0 <1.0.1 | 1.0.0-beta.1 | The range really only limits the numeric triad to 1.0.0, so we filter out all of the 1.0.1s. But the "latest" version is the highest alphabetically, so beta is returned. |
>=1.0.0-made-up-stuff | 1.0.1-z.1 | Note that the pre-release tag doesn't even exist, and moreover there is no "dot number." Bower sees no foul in this. It muses, "Ah, you want a pre-release. Here's the latest pre-release!" |
>=1.0.0-alpha.0 <1.0.0-alpha.100 | 1.0.0-alpha.1 | This actually works! Cumbersome as heck, but it does enable separation of pre-release tags. |
Hopefully this guide to how Bower handles SemVers reduces your aches and pains. If you'd like to read more, check out the section below.
1.2.3. The individual numbers are referred to, from left to right, as Major, Minor, and Patch. As your project develops, you should adjust different sections of the version number depending on how significant the change was between this release and the previous one:
>, >=, <, <=, and ^ and ~ to ask for the latest within a range of versions. For example, >=1.2.3 will resolve to the latest version, as long as it's at least 1.2.3, but under 2.0.0. >=1.2.3 <1.3.0 will resolve to any 1.2.x version, as long as x is at least 3. ^ is shorthand for the first example (^1.2.3 will get any 1 release greater than or equal to 1.2.3) and ~ is shorthand for the second example (~1.2.3 will get 1.2.3, 1.2.4, etc, but not 1.3.0). Don't worry about writing this down; there will be an examples section in part two.
repositoryCache.git.refreshTimeout from the default of 10 to something more reasonable. bower info command. Simply feed it the name of the project (such as bower info project-name), and, optionally, a version request (such as bower info project-name#>=1.2.3). Without the version request it will return a full list of available versions, and with the version request you'll see which version it resolves to, which will hopefully be your freshly-released version.git branch -r --contains 1.2.3
1.2.31.2.4-0 (a pre-release version)~1.2.3 of this library. It's reasonable to think that the resolved version would be 1.2.4-0, because it's the latest release and the version is less than 1.3.0, so it fits the description. However, it actually resolves to 1.2.3–because it prefers stable versions. It doesn't matter if a newer, fresher pre-release is available; if a stable version matches the request, Bower declares that you roll with that.~1.2.4 would resolve to 1.2.4-0.1.2.4 was properly released, and 1.2.5-0 was begun, then:~1.2.3 resolves to 1.2.4, because it's the latest stable release~1.2.4 resolves to 1.2.4, because it's the latest stable release~1.2.5 resolves to 1.2.5-0, because there is no stable release that qualifies, and that's the latest pre-release.1 or 1.2. Specifying a single digit is, in effect, specifying the major version, and saying, "I care not what minor and patch version I get, just get me the latest." In other words, 1 == ^1.0.0. Using just two digits, such as 1.2, will, as you might expect, be the same as ~1.2.0. This in itself isn't terrible, but it leads to the following...node-semver definition of the caret is that it allows changes that do not modify the leftmost nonzero digit. So if you specified ^0.0.3, 3 is the leftmost nonzero digit, and that's not allowed to be modified when using the caret, so you've basically locked this down to 0.0.3. And ^0.2.3 is basically the same as ~0.2.3.~1, then minor-level changes are allowed. That is, ~1 == ^1.0.0. Just to be clear, ~1.2 == ~1.2.0. That's a slight difference from ~1.2.3, which wouldn't pick up 1.2.0.1.2.3-0). The digit gets incremented as pre-releases are made.1.2.3-awesome-feature.0). The string identifier can only contain alphanumerics and hyphens. The digit after the dot would get incremented as pre-releases are made.awesome-project, and differentiate their work with versions 1.2.3-awesome-feature.0 and 1.2.3-killer-feature.0. Obviously they increment the .0 to .1, and so on, as needed.awesome-project's version in your app's bower.json to >=1.2.3-awesome-feature.0. And you would reasonably expect Bower to pick up the latest "awesome feature" tag, whether it's .0 or .12.>=1.2.3-made-up-stuff. We kid you not.
>=1.2.3-awesome-feature.0 <1.2.3-awesome-feature.100 or some improbably high number. This is rather unwieldy, but it does work.