My name is Christopher Bojarski. I'm a web developer, programmer and blogger. Fan of all things technology related. Avid reader and traveler. Married and living in Philadelphia. Connect with me at cbojar.net.
Minification and compression of assets (JS and CSS) is a common practice across the Web today. It improves performance by reducing the amount of data that has to be transferred over the network, without changing the behavior of those assets. Because those assets are text, the size reductions can be dramatic, especially when we use both techniques together. Using these techniques, though, is not necessarily transparent. Generally, minified assets are referred to with a .min.* extension to indicate they are different (thus, minified jquery.js becomes jquery.min.js ). Because this convention is in the file name, it must also pass down into our references: <script src="jquery.min.js"></script> . To switch between the minified and un-minified versions, we have to actually change the code in the HTML. Source maps are a different, potentially more robust solution, but require support both in the browser and in build to generate those files. Compressed assets are e
Recently I received a SunnyPeak Google Cardboard Viewer as a gift. The technology is pretty cool, allowing for any Android device to act as an inexpensive VR headset. There are a number of apps that provide interesting 3-D environments to explore. The challenge I ran into was that Google Cardboard does not work correctly on my Samsung Galaxy SIII. Instead of taking up the whole screen, the images take up only a part of the screen . A simple fix would be to change the settings in the Cardboard app, but Google made life way more "convenient" by allowing the settings to be changed only through scanning a QR code. After some Googling around, I came across a post where someone else was having the same problem. In the comments, someone had the answer . In short, the comment gives a link to a page to generate a settings QR code, and the settings to put in. After following the instructions, the app configured itself correctly and it worked great! If you are having the same probl
As software developers, we see errors every day. They manifest as exceptions or segfaults or error codes, telling us that our code has gotten into a state we didn't expect. Their appearance often portends bugs. Though we groan at an unexpected stack trace, we should see an error as a form of automated feedback . Feedback can be fast or slow. We can put the discovery of errors onto a timeline. Errors appear at many points over the lifetime of the code, starting at the moment it is compiled. The further to the right that an error appears, the longer it takes for the feedback to appear. Compile time Compile time is the earliest we can receive feedback about an error. The compiler automatically does a number of checks to make sure the code makes some semblance of sense. The most powerful tool for compile-time feedback is the type-checker. The type-checker makes sure that only values of the expected type are passed around to the places that expect them. This guards