Latest

If you aren’t bundling and minifying your javascript and CSS files, you should. It can significantly improve the load time of your web application. And if you’re working in ASP.Net, Microsoft helps bundle and minify your files with their Web Optimization tools, available on NuGet.

If you want to learn how to use the ASP.Net Web Optimization tools, read these links:

There is just one extra note I want to add – when creating a bundle, don’t put a ‘.’ in the bundle name, or it will silently fail.

So don’t do this:
bundles.Add(new ScriptBundle("~/bundles/myfiles.js.min").Include(...);

Instead, do this:
bundles.Add(new ScriptBundle("~/bundles/myfiles").Include(...);

It’s Greek to me

While working on a pull request for Knockout-Validation, I had the most bizarre thing happen: after cloning the repository, git status told me that one of the files was already modified. It turned out to be the localized text strings for Greek. Considering that I had just cloned the repository and that I don’t speak any Greek, I was fairly certain I hadn’t actually changed the file. I tried to undo changes with git checkout Localization/el-GR.js, but the file was still checked out. It seemed impossible to ‘undo’ whatever mysterious change had happened.

Google failed me

After a few rounds of Google-fu, my best guess was that something had happened related to character encoding, and some strange interaction between Git and Windows caused Git to think the file had changed. The best advice I found on the matter was to make a copy of the file elsewhere, delete the file from the repository, check in the deletion, copy the file back, add the file to the repository, commit the add, then carry on with other work. However, since I’m making changes on someone else’s project, I didn’t want to get into a conversation with them about why I’m changing the encoding around on one of their internationalization files when I really wanted to work on changing how the min and max validators worked.

4 Ways to Ignore a File

While chatting with @deathbob and @jeremy6d about the matter, Bob brought up the idea of ignoring the file by adding it to .gitignore. A good idea, but doing so would then mean that I would check in an updated .gitignore, which other team members wouldn’t like (especially the one who contributed the greek translation). Additionally, .gitignore won’t ignore files that are already part of the repository, so adding the file to .gitignore didn’t work.

However, the crux of Bob’s idea – ignoring the file – was exactly what I needed. I wasn’t sure why the Greek translation file was messed up (probably something with my system), but if I could ignore the file then I could focus on that files I actually cared about and not get sidetracked.

It turns out that there are 4 ways to ignore files with Git, and one of them solved my problem.

  1. .gitignore
  2. Global .gitignore
  3. Repository Exclude
  4. Ignoring Versioned Files

Continue Reading →

Permalink

Internationalization can be tricky, to say the least.

For .Net, you have some good tooling in place to help you create and edit resource files, which can provide text and images that can be used to support an internationalized application. But when I tried to internationalize the javascript side of an application, I didn’t find anything that looked like it would work for us.

I had been working on an ASP.Net MVC application, and I was already using .Net resource files for internationalization on the .Net side. I wanted to leverage the existing .Net resource files, because there was already a workflow for keeping them up to date and there was a good amount of text already translated that I wanted to make use of. And I wanted this data available in Javascript, because part of the application was written in Javascript.

Here is what my javascript initially looked like before internationalization:

$('#status').text("Hello World!");

The text, being hardcoded in my javascript file, was clearly not internationalized.

Continue Reading →

When working with rails, it’s quite useful to change a source file, save it, and reload a web application merely by refreshing the web browser.  This had been working great, until one day when my changes didn’t appear in the browser.

I tried clearing the cache on the browser, but it didn’t help.  Only when I restarted rails would the change get picked up.  Considering that this took a good bit longer than simply refreshing the browser, this caused a serious drain on my productivity and warranted an investigation.

After some initial searching, I discovered the config.cache_classes setting.  Here is how the documentation describes it:

config.cache_classes controls whether or not application classes and modules should be reloaded on each request. Defaults to false in development mode, and true in test and production modes. Can also be enabled with threadsafe!.

That sounded promising – all I had to do was disable caching. I went back to development.rb, and here is what I saw:

config.cache_classes = false

Caching was already disabled. But Rails still seems to be caching. What’s going on? After reading a blog post by Aaron Patterson, things made a little more sense.

It turns out that the config.threadsafe! setting in the configuration file will turn caching on. This is outlined in the documentation I quote above, but for some reason it didn’t click in my brain until I saw Aaron’s post.

Here is what we had in our configuration:

config.cache_classes = false
config.threadsafe!

So I was turning caching off, then turning it right back on again with config.threadsafe!. We needed the other threadsafe settings in our application, so we couldn’t just remove that setting, but we also needed caching to be turned off for development.

The solution was simple. I merely had to reverse the two settings in development.rb:

config.threadsafe!
config.cache_classes = false

And then we had the threadsafe settings that we needed as well as the ability to run in development with the cache disabled.

Permalink