What’s New for Web Development in Visual Studio 2012
Very important reading article for MS Web developers...
This blog is just a notebook for some mambo-jambo stuff that comes to my mind from time to time...
Very important reading article for MS Web developers...
InfoQ: Microsoft has Abandoned Silverlight and All Other Plugins in Metro IE This is an extremely important new, since it means that all IT dudes need to focus on HTML5... including me
The help manual for MS Project is less then useful for deciphering how to do complex filters. It would be nice if they just addressed it like any other language syntax. Wildcards? Reserved words? Special Functions? Anyhow, below is a list fo some standard filters you may want to use in Project. If you look closely you’ll notice a few tricks to get around the inflexible nature of Project’s filter syntax. One trick is to use the IIF operator to evaluate a statement within a custom field formula. The formula sets the field’s value then the filter evaluates that value. Another trick is used for getting around Project’s oddball treatment of “Null” or “N/A” dates. To check for these dayes you use a built-in project function e.g. Projdatevalue(“NA”).
Cheers,
Trevor Lowing
Office Tech Support
Filter Name Description Flag Field Flag Field Formula Filter Text Next Two Weeks All work scheduled during the next
two weeks.Flag5 IIf(([Start]<([Status Date]+14)
And ([% Complete]<100)) And ([Finish]>[Status
Date]),”Yes”,”No”)Flag5 equals Yes Late Start Activities that should have started
but have not or have started but have not completed.Flag6 IIf(([Start]<([Status Date]) And
([% Complete]=0)),”Yes”,”No”)Flag6 equals Yes Late Finish Activities that should have finished
but have not.Flag7 IIf(([Finish]<([Status Date]) And
([% Complete]<100)),”Yes”,”No”)Flag7 equals Yes Future Actual Or Deadline Activities where the actual complete
date is in the future or a Deadline has been set.Flag8 IIf((([Actual Start]>[Status Date]) And ([Actual
Start]<>projdatevalue(“NA”)))Or(([Actual Finish]>[Status Date]) And ([Actual
Start]<>projdatevalue(“NA”)))Or ([Deadline]<>projdatevalue(“NA”))
,”Yes”,”No”)
Flag8 equals Yes Logical Finish Activities with no
successors.Summary equals No And Successors
equalsLogical Start Activities with no
predecessors.Summary equals No And Predecessors
equalsLong-Duration Activities with a duration greater
than 40 days.Summary equals No And Duration is
greater than 40dNegative Float Activities with Total Slack less than
zero.Summary equals No And Total Slack is
less than 0dSummary-with-Pred-Links Activities with predecessor
links.Summary equals Yes And Predecessors
does not equalSummary-with-Succ-Links Activities with successor
links.Summary equals Yes And Sucessors does
not equalConstraint Not ASAP Activities not constrained “as
soon as possible”Constraint Type does not equal As
soon As Possible
Very useful...
Posted by Unknown at 11:24:00 p.m. 0 comments
Assertively frontal! :)
_________________
12 Behavior Anti Patterns You Will Face As a Software Team Leader: "
Most of these, we covered today on the 1st day of my Lead Better course that is taking place in Oslo, with live simulations. The purpose was to see how a team lead deals with these anti patterns when going through team chaos. How the team lead might act to these behaviors when the team is in learning mode, is very different than how I'd expect them to react when in chaos, as was simulated today.
This is a great demo of AJAX, HTML5 and CSS3 technologies combined together!
Watch my sample here ;)
Blogger Buzz: Fresh new perspectives for your blog: "Today we’re previewing five new dynamic templates in Blogger that you’ll soon be able to customize and use for your blog. These new views u..."
Não sei se isto é necessariamente positivo...
Portugal integra lista dos melhores destinos mundiais para Outsourcing: "

MVC or WebForms: It's more about client side vs server sideScott Guthrie has posted on the growing debate over Webforms vs. MVC, a debate that seems to be raging everywhere (although there is more that one MVC framework out there too). I agree with Scott's point about the nature of technical debates, and the acceptance that there are different schools of thought. However, that does not always imply that all schools are equally good solutions to a given problem.
The issue has been though I think not solely about the MVC pattern, it is also about the shift from providing rich client behavior server-side or client-side. In this area the renewed interest in AJAX and the emergence of Javascript libraries like Prototype, script.aculo.us and JQuery have been game changers. And for me those RIA paradigms dovetail better with MVC apps than with Webforms applications. At the same time the growth of REST has meant many have re-engaged with the HTTP protocol and its resource oriented model, have turned attention away from page based approaches to web development toward resource oriented ones. There is a correspondence here, because as the use of client side scripting grows so does the perspective of the server as a resource provider used by the client.
It is in many ways this shift of paradigm that MVC supports better and why using MVP approaches with WebForms is not a 'seperate but equal' answer to modern web development. Its not simply about better conformance to Single Responsibility Principle.
What our frameworks do for us
Our average web framework has some pretty basic requirements - handle requests for resources from the server by returning an appropriate response. In our case this is HTML. The simple nature of this model underlies the success of the web.
To support this model our framework needs to route to an appropriate handler in our code that can read the request. Now we could just interrogate that request to pull out post data or query strings, but writing a lot of that code would get old fast, so it helps if our framework can map between form, params and query string values and part of our object model. That way we can manipulate the variables of the request more easily. Now we have to take an appropriate action in response to the request. Generally this is where most of our code plugs in. We get some data and compose a response, in HTML to return in the response. Now just using Response.Write() to output our HTML becomes hard to maintain, so most of us expect our framework to give us some sort of template so that we can separate the static and dynamic portions of our response.
The MVC pattern enters the fray here when frameworks separate the responsibilities of template to provide view, model to provide response to action, and co-ordination between the two for a request. Criticism of Webforms as lacking effective separation cf concerns is because the aspx file is both responsible for rendering the HTML used as a response and providing the controller for the request. It thus has two reasons to change, because the template changes or because the co-ordination of handling a request changes. These may be orthogonal concerns and make maintenance harder. Some patterns such as MVP try to alleviate this by enforcing separation of these two responsibilities within the framework. this criticism is valid but not complete issue; the significance of 'MVC' frameworks is not solely their better separation of concerns.
Now for sure the devil is in the details, but that's pretty much it.
Bare Bones
'MVC' frameworks such as ASP.NET MVC or Monorail ttend to have a bare bones approach to meeting these requirements. The framework takes requests and calls an action to service them, mapping request to action parameters. We then carry out the appropriate task and render html through a view engine. MVC frameworks add little on top of this paradigm. The big win here is that this makes them simple to learn and easy to use, because the surface area of the API is small. The surface area for ASP.NET MVC is smaller than that for Webforms and is easier for new developers to learn. It also works in harmony with http and thus expectations. The principle of least surprise is important to APIs because it makes them easier to discover. Understand the problem and you are likely led in search of the solution.
Rich Internet Applications
Now ASP.NET MVC etc. allow you to return an HTML response, but HTML has its limitations in that it is static. You need to post a request to the server each time you want some new action to occur. In some cases this 'complete form and submit' model works, but we have become used, from smart clients, to a more dynamic model that provides feedback as we make selections. We expect choosing from one dropdown such as country to restrict choices such as US State vs. UK county or Post Code vs. Zip Code.
Out-of-the-box support in web browsers for dynamic behaviour came in the form of Javascript and manipulation of the DOM. The browser is the smart client in this approach. The issue here is that Javascript development was a challenge for many developers and consequently many development shops. Why? Because folks found client side behaviour did not just require switching to another language, but also learning the DOM, which was also sometimes uncomfortably close to metal for developers weaned on smart client Forms frameworks like Windows Forms, VB, or PowerBuilder. In addition the browser wars meant that the model for programming against the DOM was not the same from browser to browser, further complicating the code that was needed to implement a rich client in the browser. In truth it was expensive. Finally the debugging experience was poor. We were back to tracing the state of variables in order to isolate and fix problems in the browser. For many MIS departments writing sites with a rich client, heavy on javascript, was out-of-reach in other cost or skills.
To solve this problem WebForms introduces the concept of server side controls - essentially shifting the rich interaction to the server. The server side control abstracts the html control from the client side. The benefit is that it allows you a development approach familiar to forms based programmers. You set and get control properties and write handlers to react to events. But as the events are raised client-side you need effectively mirror all of the control state from the client side to the server. The problem here is that html does not share this with you on a post. You also need to record the event raised for the server side too, as a post is all you know about from http. This brings in ViewState, which captures all the state which a post is not giving you. But once it is implemented I can provide all that dynamic behaviour on the server, skipping and jumping over issues like knowledge of Javascipt and the DOM, as well as browser compatibility issues.
Of course we can quickly see that with any complex enough page ViewState will grow. As it is embedded in a page it increases the page weight which can hamper performance In addition because we must do an http post to transfer the state of our application back to the server, and then display the response, events are handled by a page refresh. This has the consequence of making the system slower than one which handles the event locally, giving rise to user complaints of flicker or slow response. In addition if you try to cope by adding some AJAX callbacks from your client the question quickly becomes 'who owns this state' as you may have copies of the state both on the client and in ViewData being marshalled back and forth to the server.
Webforms is also a more complex API than MVC and thus harder for developers to learn. Most of us have been at an interview where we have asked, or been asked the question - what is the Webforms lifecycle? Understanding the stages, where viewdata is available and modifiable is not an insignificant learning challenge.
Given that, for some time I used to recommend building applications using WebForms server-side control model over building applications with client side behaviour. Why? Because of the cost and difficulty of building rich client behaviour in Javascript with the DOM outweighed the cost of learning Webforms.
What Changed?
MVC trades the complexity of server side controls for a simpler programming model, supported by client side controls. The emergence of the new breed of Javascript frameworks like Prototype, JQuery, and script.aculo.us, made it far cheaper to code the client behaviour on the client. The elegance and simplicity of these frameworks, their abstraction of browser API differences, and their rich ecosystem of control providers, lowered the barrier to entry for client-side development providing solutions to common needs such as grids . The availability of many free controls lowers the cost of common UI widgets that have often been the preserve of expensive vendor solutions.In addition the debugging experience for Javascript has significantly improved from the old trace and dump model with browser plugins such as Firebug and Visual Studio.
With a lower cost it has become commercially viable for more development shops to build rich client applications. Best of breed applications do not suffer from the postback flicker issue because they manipulate state locally on the browser and use AJAX calls to the server. With effective client side development, the user experience is akin to smart clients of yesterday, with none of the distribution problems for central IT departments. This rich experience available for the web lies at the heart of the SaaS revolution.
The MVC model truly shines with AJAX where the target for an AJAX call is just an action on a controller. The affinity to http’s resource based model allows for easy definition of the server side support for rich clients. The advatange of MVC frameworks is the ease with which they dovetail to client-code using frameworks like JQuery. Client-side programming is back, using modern Javascript libraries!
It is this, IMO, which has shifted the balance in favour of MVC. I do not think it any accident that the ASP.NET team shipped JQuery with ASP.NET MVC. I think it was essential to shipping an ASP.NET MVC application that a modern Javascript client library was included to support rich client behaviour on the browser instead of server side.
From my cold dead handsThe attitude of many developers may be ‘you will pry Weforms from my cold dead hands’. The march of progress is threatening to do just that. Much of theresistance is based on prior experiences with the cost of client-side development using Javascript, without understanding that the new frameworks available have significantly lowered the barrier to entry there. In addition, Silverlight opens a second front against Webforms by offering rich client development using XAML. If Javascript does not replace Webforms, then XAML will. Server-side controls had their day. They built careers, companies, and fortunes but they are legacy applications now. Client-side controls have returned with fresh offensives that will see their end. If you are building a new web project today you should be looking at an MVC framework.
For my part the question of Webforms vs. MVC is already an irrelevance. That is yesterday’s fight and victory has been declared despite a few units continuing to fight on. The next war is likely to be between Silverlight and Javascript for ownership of the smart client…
Posted 01-27-2010 3:34 AM by Ian Cooper
Best and most complete article I have ever read about this subject.
Let me underline these two citations, that I subscribe:
"If Javascript does not replace Webforms, then XAML will."
"The next war is likely to be between Silverlight and Javascript for ownership of the smart client…"
The missing comparison: :)
NHibernate vs. Entity Framework 4.0
Posted by Unknown at 2:53:00 p.m. 0 comments
Really useful (and long) article!!
Posted by Unknown at 12:01:00 a.m. 0 comments
I've just passed the exam today!
I almost "missed by that much!", as Maxwell Smart would say! I scored 700, the exact passing score!
So now I am a MCPD: Web Developer. Let's hope it means something...
Kudos to me... :)
If you are looking for a MS Project replacement, then this is your savior!
And look... it's free! And compatible with MS project mpp files!
I'll definitely give it a try :)
Sector das TI tem falta de trabalhadores na região norte
COMO?!?!?! Vamos contar quantas ofertas de trabalho aparecem para a zona do Porto? E se descontarmos ofertas para estágios, quantas restam? Pois, quase zero. E em Lisboa? É melhor nem comparar...
Razões para isto? Para mim duas: a "moda" de que todos os serviços se fazem em Lisboa - de tão pequeninos que somos, ainda nos queremos fazer mais, do tamanho de Lisboa - e a tacanhez dos industriais do Norte que insistem em investir nos novos modelos de automóveis desportivos em vez da inovação tecnológica e competitividade.
"O facto de a maioria dos candidatos a empregos em TI voltar as atenções para Lisboa é outro dos factores que tem condicionado a falta de trabalhadores na região norte, uma das que possui a maior taxa de desemprego do país." - Mais uma vez, COMO?!?!?! Talvez os candidatos voltam as suas atenções para Lisboa porque A OFERTA DE EMPREGO NO NORTE É ESCASSA!
Acho que alguém anda a por aí a fazer o pino enquanto tenta fazer jornalismo...
Another great article.
Here's an excerpt:
"
Hafta is really a design mindset - albeit an especially poor one. Broadly speaking there are three attitudes to design:
1. We hafta do it this way because...
2. Wouldn't it be great, if it could work this way...
3. My grand design is just getting started!
"
Hafta Man and the threat to agile design | Reg Developer
Posted by Unknown at 2:30:00 p.m. 0 comments
Awesome article: Tom Hollander's blog : Thoughts on being a Solution Architect
Posted by Unknown at 1:48:00 p.m. 0 comments
This is a very good and simple article about dependency injection, IMHO: Loosen Up: Tame Your Software Dependencies for More Flexible Apps
Posted by Unknown at 11:49:00 a.m. 0 comments
Great great article! I shall say that I fall often in mistakes 17 and 18.
Worth reading.
Posted by Unknown at 12:31:00 p.m. 0 comments
Scrum Log Jeff Sutherland: Scrum in 5 Minutes
For all of you who care about methodologies to manage software development projects, here's the most concise and useful Scrum (the most famous of so called Agile methodologies) description I've ever seen!
Posted by Unknown at 3:35:00 p.m. 0 comments
Seven Habits of Highly Effective Programmers
For those "fellows in work" out there, this article is really worth more than a glimpse.
Posted by Unknown at 9:55:00 a.m. 0 comments