Wednesday, 28 de October de 2009
por climens
After some research, I posted a question at stackoverflow.com without much success, but the problem was that the answer was already there.
I you are working on any application that needs to serve files on it’s own, for example for encrypted storage or a rich ACL that needs to be enforced, you will need to provide the most correct Content-Type possible or MIME type from a given file extension to the reponse in order to achieve the best user experience.
For example, if you serve a PDF and use a generic MIME like application/octet-stream, the user may not se a PDF reader to open it, depending on the browser and platform.
Then, in .NET there are 4 alternatives to do this, with their pros and their cons:
- Use the Windows registry – This may be a good solution for desktop applications but depends on the software installed on the machine and typically web servers don’t have Acrobat or Office.
- Use urlmon.dll’s FindMimeFromData – I don’t know exactly the efectiveness of this method, but it’s used internally by Windows. It should give good and reliable information but you have to read the file and give the method up to 256 bytes of the file header.
- Use IIS information – Maybe the most obscure mechanism, based on Directory Services and COM stuff. It’s based on the same mechanism IIS uses, so it should be quite reliable, but complex and may not be the fastest.
- Use your own dictionary – Maybe not the most elegant but even .NET uses this internally (see System.Web.MimeMapping… you know how). You get a bunch of types from somewhere and add them to a dictionary with the associated extension. Easy.
So, the optiones are clear. Finally in my case, I used a simple dictionary to ensure compatibility between platforms and homogeneity. Using other mechanisms could lead to strange errors on some platforms that I wanted to avoid over other benefits. But there are much more elaborate mechanisms that can be done.
Wednesday, 05 de August de 2009
por climens
I’ve seen many ASP.NET MVC samples and some of them do not honor de ReturnUrl parameter, rendering this unusable.
Classic ASP.NET has the login form component that puts the same exact URL used to access the login page in the form action URL, preserving the ReturnUrl parameter and then, FormsAuthentication.GetReturnUrl() gets it from the Request.QueryString collection.
Fortunately, the GetReturnUrl() method looks as well in Request.Form in case there’s nothing in the query, this way, we can use a hidden field as well to store the ReturnUrl in the View and pass it through POST when the login form is submitted.
So, in ASP.NET MVC we have two options:
- Use simply
Html.BeginForm() without parameters, which will put a simple form tag, with the same URL as the current one and use POST by default
- If we want to have more control on the
Html.BeginForm(), put a hidden field with the value of the ReturnUrl, only if the ReturnUrl is not empty, or it will fail. This can be obtained from the Request.QueryString collection, the ViewData if we put it previously on the Controller action or even better store it in the ViewModel and have a strong typed reference.
And that’s it. Then, FormsAuthentication.GetReturnUrl() will get the proper URL and other methods like FormsAuthentication.RedirectFromLoginPage() will also work seamlessly.
Tuesday, 28 de July de 2009
por climens
El nombre del principio es el acrónimo del inglés Keep It Simple, Stupid o Keep It Short and Simple. El sentido, se puede imaginar. Es en realidad la aplicación de lo que se conoce como La Navaja de Occam (Ockham’s Razor) aplicado a la informática. Todo se basa en una simple premisa: “dadas dos soluciones a un problema determinado, la más simple es probablemente la correcta”.
Aplicado al mundo del desarrollo de software, lo que se conoce como el principio KISS, implica resolver los problemas del modo más sencillo posible y posiblemente ésta sea la mejor solución.
Código
Desde el punto de vista del código tiene más implicaciones a parte de la simplicidad:
- Un código más simple es más sencillo de mantener, lo que ahorrará tiempo en el futuro.
- Además, será más sencillo de comprender por cualquier persona que entre en el equipo de desarrollo.
- Cuesta menos de escribir
- Menos lineas equivalen a menos bugs, lo que significa código de mayor calidad
Gestión de proyectos
Pero todo esto carece de sentido si desde no se tiene también en cuenta desde el nivel de gestión de los proyectos de software. Es estupendo pensar en miles de funcionalidades para un producto pero ¿qué sentido tienen? Primero habrá que hacer lo más simple para luego ir añadiendo más cosas a una base sencilla y comprensible.
Hay que construir software sobre una base sólida y unos requisitos simples y concretos. Esto permitirá desarrollar unas funcionalidades simples y robustas en menos tiempo y una vez el producto tiene cara y ojos, se pueden ver las carencias y se pueden encontrar nuevas posibilidades.
Pensar en cientos de funcionalidades, además tiene otras implicaciones menos obvias:
- Tests de usuario menos frecuentes pero mucho más complejos y largos.
- Bugs más difíciles de encontrar y de solucionar.
- Time-To-Login (tiempo entre que se empieza el desarrollo hasta que se tiene una primera release) mucho más alto.
Muchas de las metodologías ágiles se basan en parte en este principio para desarrollar un software evolutivo en vez de crear gran cantidad de especificaciones y documentos que pueden tardar años en implementarse y meses en integrarse.
En resumen, antes de escribir un método, piensa si no lo estás complicando demasiado y antes de añadir un requisito a una release… piensa si realmente es necesaria en ese momento. Recuerda: KISS.