are models for which every day would agree to rotate slowly platforms and infrastructure software.
project management discipline there is also profound changes taking place and the profile of PM & Manager traditional mere pushers & dispatcher activity, are showing in the cord, too ... In fact
is increasingly making its way to the reference model of PM & Manager with strong technical skills ... business and attention to costs, profits and budget ....
These are ideal for those PM connector between technical areas and business and these are Profiles of the real catalysts activity and charged to businesses.
difficult problems arise with these profiles of efficiency and effectiveness of the structures ... because it is managers who have already demonstrated in the field, and all the teams involved, to be technical and business experts at the same time ...
Increasingly we happen to explain what are the RSS feeds and what are the potential of this simple tool. 
The web is changing so rapidly the balance of power between those who produce the content (and holds the possibility of access and distribution) and the reader. player that now is no longer taxable, but is himself an active part of the selection process and content creation.
and RSS are the opener a very low impact substantial enough for this paradigm shift in progress ... Here's the link
http://www.youtube.com/watch?v=8FmePY7dwDg
This video is considered the Manifesto Web 2.0
It 's a video of Michael Wesh, professor of Cultural Anthropology at Kansas State University, says that in less than 5 minutes the revolution in progress.
survive and be on the edge of technology only businesses and communities that have successfully adapted to the new way to communicate and build relationships of a sentimental, commercial, political and cultural.
discuss what the process more efficient or better suited 
The IT Architect are intermediate figures that address the technical choices of the IT team and also particularly in light of their economic importance ... and therefore must take account of 'Economic meltdown in place and act accordingly.
And now they say the Anglo-Saxons as a joke ... these are times when the Chief Financial Officer CIO become true!
Gartner recently issued a sort of operating handbook (25 suggestions) on how to operate an effective cost control attraverso i quattro versanti trasversali dell’IT:
- IT management
- enterprise software
- enterprise infrastructure and operations (networks and telecom)
- enterprise infrastructure (hardware & IT operations)
Eccoli di seguito:
Cut costs through more effective IT management methods
-Focus initially on cutting "people costs": Freeze headcount, reduce/eliminate special bonuses, reduce regional support.
-Flatten organization structure: Move to collaborative, team-based models .
-Accelerate the progress of centralized and shared services: Leverage enterprise-wide competencies, reduce staff embedded in business units.
-Bring a qualified finance person into your IT leadership team, perhaps on loan or on temporary contract.
-Maintain or strengthen relationship management roles: Business analysts, business process and industry experts, account executives, relationship managers.
-Take control of "unmanaged" costs you can measure and cut easily, such as data center power consumption or printing.
Cut costs in enterprise software (Caution ahead!)
- Use invoice verification .
-Eliminate unused software/modules. Understand who's using what and why. Lots of closet cleaning here.
- Apply more sophisticated negotiations ."You can't put someone who bought pencils into a negotiation" with a big software vendor, Gartner's Bill Snyder said. "They'll get eaten alive."
-Use alternative products included in previous deals.
- Introduce competition for existing products . You must foster vendor competition if you hope to lower costs. If you decide to switch, make sure you calculate the cost of taking out the incumbent beforehand.
-Use "best-for-need" rather than "best-of-breed" products. You could be paying as much as a 50% premium for best of breed, Snyder said.
Cut costs in enterprise infrastructure and operations: Networks and telecom
-Use telecom expense management services (save 10% to 35%). Nobody can keep track of this stuff. Hire a professional to source, benchmark, negotiate the contracts, etc., and audit the bills.
-Move to corporate liability for wireless services (save 15% to 30%). Who's responsible for the bills of individuals, what devices they use? The enterprise should take control and set standards, Gartner analyst Phil Redman said.
-Reduce the reliability target for a location by "one 9" (save 30%).
-Collapse rich media conferencing into a premises-based multi-control point unit (save 60%). As hardware costs come down, building your own videoconferencing center can save big money over the long run, assuming you do a lot of it.
-Deploy IP telephony and Voice over Internet Protocol (save 50% to 80% of maintenance).
- Use the Internet as corporate transport (save 10% to 80%).
Cut costs in enterprise infrastructure, hardware and IT operations
-Defer 2008 Windows XP PC replacements to 2009. Three-year-old PCs and 2-year-old laptops might be able to go another year, but you should be mindful of the maintenance costs, Gartner analyst Michael Silver said.
-Exploit commoditization: the best-for-need instead of best-of-breed argument, redux.
-Make better use of existing tools by improving process and policy.
- Defer client architecture pilot/evaluation projects. -Implement
thin provisioning and data de-duplication for storage reduction.
- Consolidate and virtualize servers .
Emerging trends in IT cost pressure
Target Areas for two or three "zero-based budgeting in 2009.
Start the process soon Gartner said: "Current-year cost-saving opportunities will be Revealed."
1. Before you let it run, then make it fast ! This is true even if you are certain that any piece of code is really important and that it will become the main bottleneck of your system. Do not touch that fragment to optimize it. First of all try to get a working system with a project as simple as possible. Only later, if it is not fast enough, think about it. Almost always find that the real problem is not "your" bottleneck. Save time for what is really useful.
2. elegance in coding always pays. It is not frivolous activity. You will hand in a program not only easier to compile and test, but also easier to understand and maintain: and this is where you find the economic value of your work . You may need a little 'first experience to understand this fact, as it might appear that, as you seek to make a smart snippet, you are not really productive. Productivity will emerge later when the code will integrate seamlessly into your system, and even more when the code or the system will be changed.
3. Remember the principle "divide et impera " . If the problem you are facing is too complex, try to imagine what might be the basic operations of the program. Perhaps imagining a "something" to deal with the most difficult parts!
This something is an object and then write code that uses that object. Then analyzed the object and encapsulated within its intricate parts of other objects, and so on.
4. If you have a large block of code that needs to change, begin to isolate the parts that will not change possibly being included in a "class API" as static methods. Next, focus your attention on the code that will change, restructuring it into classes. Thus makes easier the changes as your business maintenance will proceed.
5. Keep the distinct from its creator class user (client programmer ). Who uses the class is the "customer" and does not need nor want to know what happens behind the scenes. Who creates the class must be the expert in designing classes and must write it so that it can also be used by most novice programmers, continuing to behave in a robust application. The use of any library is simple only if it is transparent.
6. When you create a class, use a nomenclature as clear as possible . Your goal is to make the programming interface is conceptually simple. Try to make your names so clear as to make unnecessary comments. To this end, exploited overloading of functions and default arguments to create an intuitive, easy to use.
7. The control allows you (the creators of the class) to make extensive changes in the future that will then be possible without adversely affecting the client code where the class is used. In this perspective, keep everything as private possible, and make public only the class interface, instead of always using the data functions . Make the data public only when you are forced. If users do not need a class to invoke a function, declare it private . If a part of your class must be visible to any classes inherited as protected , provides an interface to functions rather than expose data directly. In this way, the changes implemented will have minimal impact on derived classes.
8. First of all, and if possible write the test code . Even before I write the class and then keep evolving along with the class. Make the automatic execution of your test perhaps through a makefile or by an instrument similar. In this way, any changes can be controlled automatically by running the test code, and errors are immediately detected. Knowing that I have the safety net of the test environment, you will be more likely to make significant changes when they feel the need. Remember that the major improvements in programming languages \u200b\u200bcome from internal controls provided by type checking, exception handling, and so on, but these features are to a certain point. You have to get down the road that leads to the creation of robust systems by introducing the tests that verify the specifics of your class or your program.
9. Remember a basic rule Software Engineering: All the problems of software design can be simplified by introducing an extra level of dereference conceptual. This idea is behind the ' abstraction, the primary feature of object-oriented programming.
10. Make the most atomic classes can in other words, give each class a single clear purpose . If your classes or your system design becomes too complicated, break complex classes into simpler classes. The most obvious sign of this is exactly the same size: if a class is large, there is the possibility of doing too much and then you need to analyze it.
11. Beware long method definitions. A long and complicated operation is difficult and expensive to maintain, and is probably trying to do too much alone. If you are to handle such a function, means that, at least, should be divided into several smaller functions. It could also suggest the creation of a new class.
12. Beware long argument lists. Function calls are hard to write, read and maintain. Rather, try to move the method in a class which is most suitable, and / or pass an object as a parameter.
13. Do not repeat yourself . If a piece of code appears in many functions in derived classes, move that code into a single function in the base class and call the functions of derived classes. Not only save space, but allow easy propagation of changes. You can use an inline function perl'efficienza. Sometimes, the discovery of this common code brings considerable benefits to the functionality of your interface.
14. Beware of instructions switch or the if-else concatenated. Typically, this is a clear indicator of the type of programming type-check . Programming
type - check means that you are choosing what code to run under some kind of type information (the exact type could not be immediately apparent). Usually, you can replace this kind of code using inheritance and polymorphism, the polymorphic function call to perform the type check for you, and allow for a more affordable and easier extensibility. [NDT - In reality, the type checking is characteristic of the C + + is a strongly typed language, but the principle is still valid as a point of attention of a general nature in the sense that an excess of if-else statement nested is certainly index entropy high you are entering in the code.]
15. Look limitations in the inheritance . Projects cleaner add new features to those inherited. Beware of a project that removes the old functionality (while you are inheriting) without adding more. But rules are made to be broken, and if you are working with an old class library could be more efficient to restrict an existing class in its subclasses, rather than restructure the hierarchy so that your new class you go to where it should enter, above the old class.
16. not to extend the core functionality in subclasses . If an interface element is essential for a class should be in base class, and not be added during the derivation. If you are adding methods through inheritance, perhaps you should rethink the project.
17. Less is more. Started by minimal interface for the class, simple and small enough to solve your current problem, but do not try to anticipate all the ways in which your class could be used . At the time of use, you will discover the way in which you have to expand the interface. However, once the class is in use, you can not modify the interface without disturbing the client code. If you need to add more features, all right, will not create problems with the code, if not the need for recompilation. But even if the new methods replace the functionality of the old ones, let alone the existing interface (if you want, you can combine the functionality in the implementation below). If you need to expand the interface of an existing function by adding new topics, leave the existing arguments in order, and assign default values \u200b\u200b to all the new ones, in this way, you will not create any problems to call existing that function.
18. Overloading of operators is only "syntactic sugar " a different way to call a function. If overloading an operator does not make the class interface clearer and easier to use, do not. For a class create a single operator for the automatic conversion type.
19. Do not worry about premature optimization. It is pure folly . In particular, do not bother to force the code to be efficient when you are just building the system. Your main aim is to test the project, unless it requires the same degree of efficiency.
20. Keep the scope as small as possible, so that the visibility and the life of your objects are the lowest possible level. In this way, you decrease the possibility of using an object in a wrong context, and to hide a bug hard to find.
21. Avoid, avoid, avoid as much as possible ... we will never tire of repeating, the global variables. Always try to insert data into classes. It is more likely to run into global functions rather than global variables, even though you might realize later that a global function would be a more appropriate location static as a method of a class.
22. Take advantage of your benefit check for errors made by the compiler. Compile your code enabling all warning, and correct your code inmodo to eliminate them all. Write code that uses the errors and warnings at compile time rather than code causing runtime errors. Use assert for debugging, but to use the runtime exceptions.
23. Favorite compilation errors to runtime errors. Try to handle an error as close as possible to the point where there was . It is preferable to handle the error at that point rather than throw an exception. Catch the exceptions in the handler closer than having enough information to handle them. Do everything you can with the exception to the current level and if this does not solve the problem, rilanciatela again.
24. not create your own notation "custom" for the names of member variables ( underscore , prefixes, imaginative variations of Hungarian notation, and so on), unless you have a lot of pre-existing global variables; if not, let the classes and namespaces do the job for you.
It is said that von Neumann designed the scheme of MAG in minutes, immediately after realizing that the designers of what became the ENIAC were groping in the dark ... Absence of Intuition in darkness. Much the same Von Neumann in that we see a historic photo below along with Oppheneimer and ENIAC.
Hinchcliffe is clear and immediate. platforms Social Network, according to Hinchcliffe, agrees to extend and deploy them in particular:
In this respect, unfortunately, are very symptomatic attitudes of closure (blocking Internet ports, for their employees, to all the Web 2.0 platforms like Twitter , Facebook, YouTube , Microsoft Instant Messenger Messanging as ...) that many European companies are implementing in a systematic way against the Web 2.0 that is rampant on the Internet now.
ramp and expand the Web 2.0 platforms and like all new technologies are also a little 'fear!
There is certainly a misunderstanding about what Web 2.0 and how they are viral accelerators and catalysts of knowledge ( Internal Knowledge ) social networks and therefore do not understand the closing also media (see increasingly aggressive campaigns Facebook to denigrate the traditional media - print and television in particular - though in that case maybe it was before a battle between competitors !) In such technologies.
In the end, however, this feeling of isolation was the same as businesses and not only they had years ago to the whole Internet world in the initial phase of its expansion.
The extreme paradox then is that often companies that block and close platforms like Facebook or Messenger are the same ones that are maybe planning to sell or provide to their customers, collaboration platforms Web 2.0!
E 'apparent contradiction, and therefore was confident, along with Dion Hinchcliffe, that such conduct, even if we are at the bottom of schizophrenics, sooner or later will be reconsidered ...
