As a web developer, it is very common to have the need for an image server. Usually the requirement is pretty straight forward: We need to dynamically re size an image. This is very common when you display thumbnails and regular size pictures in a site.
Personally, I also like to have a single source image; that way, I don’t have to create all the sizes I need before hand. But most importantly, if I need a new size in the future I don’t have to create that new size for all the images I already have.
When working on enterprise environment, people tend consider only solutions by big companies which tend to be pretty expensive. People that can’t afford these solutions try to create the component them selves, which can be very time consuming (if done correctly).
I’ve been u sing Spry Photo for a while (http://www.spryphoto.com/). You can see it in action in http://www.clickclassified.ca and http://www.storybank.com.
Continue reading “SpryPhoto – An excellent and affordable image server”
On October 29-07, I attended the real development event in Toronto presented by Jean-Luc David. I found this event interesting because it was really targeted at developers; it was mainly all demos, and the best part is that they showcased some interesting tools to help us develop better sites.
Not all of the tools shown where new to me, but they were used in a way made those tools that I was already using even more useful. Important to notice that the majority of the tools are free.
I plan to present here a summary of all the tools they used, with a bit of description. I believe this will be helpful to the development community that couldn’t attend to the event.
Continue reading “Tools from MS Real Development 07 – Toronto”
As a Web Developer, I’ve frequently have had the need to make asynchronical function calls.
Usually, you need to do async calls when:
- Function takes a long time to process
- There is no need to present a response to the user
In this example, I will be showing some code I use on my Facebook Application (Network Trotters) to update the users profiles.
As a quick contextual background, user profiles are cached on Facebook’s side, and periodically I need to clear the cache so it is updated. This action can take a bit of time when you have a high number of users, but it doesn’t really require any response to the user.
There are 3 main things you need to do to create an async call:
- Create a delegate with the signature you would like
- Implement a Function with the same function as the delegate
- Call the delegate
Continue reading “C#: Asynchronical Function Calls”
Originally written on June 2006
This message is relevant to all of us who build ASP.Net applications that are being deployed into a Web Farm/Garden. A small modification will have to be done in the web.config to avoid view state inconsistencies.
The problem is that the ViewState on ASP.Net pages are encoded based on a Key. By default an application will use the key on the machine.config file, which is auto generated, thus, different in every machine (server). If an application runs in a web farm, then there is a potential of having inconsistencies in the way the ViewState is encoded/decoded.
The solution is to set a the key used for encoding in the web.config… and setting it to a static key. This way all the encoding/decoding of the ViewState will be done with the same Key, and there will be no problems. Plus the Key will have an application scope, instead of a Server scope (which has when uses the machine.config).
The setting in the web.config is something like this (the one below is an example only):
<machineKey validationKey=”21F090935F6E49C2C797F69BBAAD8402ABD2EE0B667A8B44EA7DD4″ decryptionKey=”261F793EB53B761503AC445E0CA28DA44AA9B3CF06263B77″ validation=”SHA1″ />
<!– OTHER SETTINGS –>
It is recommended to have different key setting for each application. Here are a key generator:
Machine Key Generator
So, basically, if our application is on a web farm, or we think it will be, it is recommended to add a machine key section in our web.config.
Originally written on April, 2006
ASP.Net 2.0 has introduced a few new different concepts in regards of dll generation and deployment.
In ASP.Net 1.x, all your class files would get compiled into 1 dll and that was it. In the new world there are actually 3 options:
- You release everything including class files and they get compiled on the fly. This means nothing of the web application gets copied to the bin folder.
- You release only binaries. Everything, including ASPX pages are pre-compiled (If you open the ASPX file after the compilation you can’t see your client side code). This means everything is in the bin folder, pretty much one precompiled file per file in your application.
- A mix of the 2 above (and the most similar to ASP.Net 1.x). Every class gets compiled, but ASPX pages remain normal. Even in this scenario, multiple dlls get generated per project.
One of the main challenges here is the version management; you can not implicitly assign versions (no AssemblyInfo.cs in web apps), plus there are multiple assemblies generated.
However, there is a command that will merge all your dlls (per application) into one, applying versions, signatures, etc. The utility command is called aspnet_merge.exe. It is important to know what it does, but notice that we won’t have to use it directly as Microsoft has now released it as an Add-On for Visual studio.
The Add-On is really easy to use, and I would recommend we all get familiar with it. You can get it here: http://msdn2.microsoft.com/en-us/asp.net/Aa336619.aspx