Additional adjustments to make Windows 8 look better in a MacBookPro with Retina Display

Apple did a very decent job on the default way that Windows 8 looks when installed in a BootCamp partition, however, there are still a few quirks that need to be fixed, like:

1. The size of the title of each window.
2. The font size in a Console or Git Bash window.

Pretty much every website that has reviewed Windows 8 in the MacBookPro with Retina Display already suggests changing the scaling of the fonts to custom, 200%, and that is the sweet spot for that. However, I haven’t seen that any of those sites suggest to fix the default font size for the title of each window, which is so small that just shows as 3 or 4 dashes. The weird thing is that after testing the initial adjustment to do it, the smallest setting does look legible, not the way it looked as it did the before making an adjustment at all. So, whether it looks illegible to you or just really small, it would look like this:

Uhm, the screenshot looks huge on regular resolution. The thing is if you’re using the default resolution of 2880 x 1800, the font size of each window will look illegible.

To change the size, just go to the Display panel of Windows (Right click on Desktop, Personalize, select Display on the left side panel), and on the lower side of the panel you will see the “Custom Sizing Options“. Select “Title bars” from the dropdown, and change the font size to 10 or whatever you feel comfortable with. Then, titles will look way better, like this:

So, onto the next thing. If you use the Command window, or the Git bash window, the font size looks terrible as well. And even if you manage to change what appear to be the defaults, or change the font size for the current window, the next time you launch the program (in the case of Git Bash), the font size will look terrible again, like this:

As I said, you might’ve tried to right click on the title bar and change the font size using the Defaults or Properties menu option. But you will realize that Windows just will not preserve the changes if you do it that way. In order to get it to work, you have to:

1. Open a Windows Explorer window
2. Locate the Git Bash shortcut in C:\Program Files (x86)\Git
3. Right click it, select Properties.
4. Go to the Font tab.
5. Make whatever changes suit you.
6. Hit Save. Windows will say you need to provide Administrative privileges to make that change. Click Continue.

And that’s it. Everytime you launch the Git Bash from now on, the font size will be whatever you set it to be. As for the Command window, actually changing the Defaults will work. Just:

1. Launch a Command window (Run -> cmd -> Enter)
2. Right click the icon on the top left corner, select Defaults
3. Go to the Font tab.
4. Change the font size to whatever you want, click OK.
5. Close and re-open the Command window. Font looks good now.

That’s one of the quirks I faced today, and hopefully it’ll save someone some Google time. Hope it helps.

Javascript remove spaces method alternative

I had a custom javascript method that used regular expressions to replace all spaces in a given string, but just found an alternative that is worth knowing.

var str = 'this is some text';
var replaced = str.split(' ').join('+');

Will output “thisissometext”.

I have yet to check which is more performant, but at least it’s handy when doing javascript development and I don’t have my personal custom library around.After reading some more, performance results vary a lot depending on the browser used.

You can run some javascript comparisons of regex replacement vs split-join to see for yourself.

ASP.NET Bundling and Minification Gotcha #1 – Javascript bundle not rendering

ASP.NET Logo

Having used a couple of other bundling and minification libraries like Cassette and RequestReduce in the past, I started playing with the new bundling and minification features in ASP.NET 4.5. While setting up bundles is easy, there are quite a few gotchas that are not yet fully documented on the web.

This specific situation/gotcha took me a couple of hours to figure out, and I almost gave up on using Microsoft’s bundling completely.

In order to ease debugging for us developers, bundling and minification only happens if one of the following conditions are met:

1. You’re running with <compilation debug=”false”> on web.config (or without the attribute at all)
2. You force Bundle Optimizations to be ON by specifiying BundleTable.EnableOptimizations = true; on the RegisterBundles method.

When you’re running in debug mode, the files specified on bundles will not be minified or bundled, and tags will be rendered for each file in the bundle.

While that is great, the problem is the way Microsoft assumed that all developers have both development and release versions of each script that they use. As in, if you’re using jQuery, and you want to add jQuery to a bundle, Microsoft will expect you to have both the jQuery-1.8.0.js and the jQuery-1.8.0.min.js files added to your solution.

If you only have the .min.js file in your project, you configure your bundle to use that already-minified script, and you’re running in debug mode, any .min sripts will not be rendered in debug mode. What’s worse, if you only had .min.js scripts in that bundle, nothing will be rendered for it, as if it did not exist or was not configured, nada. No HTML tag for it.

Why?

Because as this StackOverflow question’s accepted answer states, there is a default ignore list that is enforced when rendering the bundle, and for debug mode, all *.intellisense.js, *-vsdoc.js, *.debug.js, *.min.js and *.min.css files are completely excluded from being rendered, because again, Microsoft assumed that you have both release and debugging versions of the scripts or stylesheets that you use in your project.

To be fair, the official tutorial on ASP.NET Bundling and Minification, does mention of some of the conventions, but it can be confusing. The post states:

“Selecting the non “.min” version for debug.”

“Selecting” implies you have choices. If a project only has release (.min.js) versions of a script, they are not added. If they had two choices, but one of the choices is not even an option in the situation, they should default to the other option, not to ignore the script. The post should have stated

“Only non .min versions are included for debug”

Their intention is good, but I believe the assumption/implementation is a bit flawed. I feel if they’re going to ignore a file that you explicitely specified in your bundle configuration, they should at least check for existance of the debug version of the script in your project before ignoring your request to add the release version to the bundle.

So, in order for your bundle to render those .min.js scripts, you have two choices.

1. Just add the debug version of the script you want to use to your project.
2. Clear the ignore list of the bundle (or just the entry you do not want ignored), although there might be side effects to that if you have other scripts of which you do have both versions.

Hope this saves someone a headache.

Bug en Subsonic 3.x al comparar instancias de objetos

He utilizado Subsonic de Rob Conery por varios años, desde sus primera version.

Es un ORM decente, hecho por un buen desarrollador. Subsonic ya no se desarrolla activamente (ahora se enfoca en Massive, su micro ORM), pero la ultima version, 3.0.0.4, sigue siendo utilizada por varios proyectos.

Hace algunas semanas desarrolle una funcionalidad nueva en un proyecto existente, que utilizaba Subsonic, y al estar probando la funcionalidad descubri un bug en Subsonic y la manera en que compara instancias de objetos de la misma clase, haciendo que siempre regrese false en una comparacion.

El codigo problema esta en el metodo Equals, generado por el template T4 de ActiveRecord de Subsonic:

public override bool Equals(object obj)
{
    if(obj.GetType()==typeof(Entity))
    {
        Entity compare=(Entity)obj;
        return compare.KeyValue()==this.KeyValue();
    }
    else
    {
        return base.Equals(obj);
    }
}

Y el metodo KeyValue hace esto:

public object KeyValue()
{
    return this.EntityId;
}

Al estar comparando dos objetos, este metodo es llamado, y si los objetos que se estan comparando son de la misma clase, ejecuta la linea

    return compare.KeyValue()==this.KeyValue();

El metodo KeyValue() simplemente regresa el valor del campo que este asignado como Id de la clase, ya sea un entero, un GUID, long, etc. El problema es que regresa el valor casteandolo a tipo object. Es decir, la siguiente comparacion regresara false, incorrectamente:

    bool testOne = (object)5 == (object)5; //this will return false

No importa que estamos comparando un valor constante, porque lo estamos casteando a ser de tipo object. La comparacion correcta seria comparar los objetos directamente (sin castearlos), o utilizando el metodo Equals de la misma clase.


    bool testTwo = 5.Equals(5); //this will return true, as we expect.

Entonces, para corregir el bug en Subsonic, se puede actualizar el template T4 de la siguiente manera:

public override bool Equals(object obj)
{
    if(obj.GetType()==typeof(<#=tbl.ClassName#>))
    {
        <#=tbl.ClassName#> compare=(<#=tbl.ClassName#>)obj;
        return compare.KeyValue().Equals(this.KeyValue());
    }
    else
    {
        return base.Equals(obj);
    }
}

Es decir, reemplazando la comparacion anterior (que usaba el operador ==) con una llamada explicita al metodo Equals de la instancia del objeto que estamos comparando.

Espero les sirva.

1 2 3 4 5 31  Scroll to top