Welcome to the blog Hitech Tips

A blog about web and IT. Sharing things I use at work.

Notion Ink's ADAM

Posted by Mr.Editor Thursday, February 25, 2010 2 comments

 

image

Três aspectos que me parecem interessantes:

  • câmara rotativa - permite trabalhar e filmar uma apresentação ao mesmo tempo (com a câmara a 90º)
  • toutchpad nas costas do aparelho
  • excelente visibilidade mesmo com luz solar directa

Mais informações no Aberto até de Madrugada

New Wordpress template: Libetarion / web2feel

Posted by Mr.Editor Monday, February 22, 2010 0 comments

Liberation WP theme

Liberation is the latest News- magazine type of wordPress theme from web2feel.com. This is a widgetized 3 column theme with a magazine layout for the home page. Theme holds a featured post section in which posts from a featured category is displayed in a tabbed content style. a The home page displays latest posts and posts from specific categories. Theme also comes with a customizable “about us section” , Twitter widget, Featured video etc. There is a screencast explaining the setup process of the theme.

Links:

The designs made by  Jinsona / web2feel.com are inspiring and it's worth a visit to its website. As if not enough, these templates are available for free!

Vaporware: Microsoft Courier Tablet Booklet

Posted by Mr.Editor Sunday, February 21, 2010 0 comments

Old news from September 24, 2009:

It looks like Microsoft is taking an exuberant stab at stealing the Apple Tablet's thunder. Microsoft's Courier tablet ...err "notebook" computer is reportedly in the "late prototype" stage of development. It is a tablet style computer that features dual multi-touch 7 inch displays in a clamshell configuration. A video posted on YouTube by Gizmodo (see below) demonstrates a mock-up of its exceptionally advanced interface. While there's no promising that this device will ever actually make it to production, if it does, it will satisfy the demands of both the tablet and netbook markets. (more)

 

 

Well, if it does what the video shows, then I'll want one of theese!

 

image

 

image

 

image

 

Pictures source

 

Let's see if this is just vaporware agains the Apple iPad.

An interesting post from the Facebook engineers about how they made the Facebook twice as faster.

 

Making Facebook 2x Faster

by Jason Sobel (notes) Thu at 11:25pm

Everyone knows the internet is better when it's fast. At Facebook, we strive to make our site as responsive as possible; we've run experiments that prove users view more pages and get more value out of the site when it runs faster. Google and Microsoft presented similar conclusions for their properties at the 2009 O'Reilly Velocity Conference.
So how do we go about making Facebook faster? The first thing we have to get right is a way to measure our progress. We want to optimize for users seeing pages as fast as possible so we look at the three main components that contribute to the performance of a page load:network time, generation time, and render time.

Components Explained


Network time represents how long a user is waiting while data is transmitted between their computer and Facebook. We can't completely control network time since some users are on slower connections than others, but we can reduce the number of bytes required to load a page; fewer bytes means less network time. The 5 main contributors to network time are bytes of cookies, HTML, CSS, JavaScript, and images.
Generation time captures how long it takes from when our webserver receives a request from the user to the time it sends back a response. This metric measures the efficiency of our code itself and also our webserver, caching, database, and network hardware. Reducing generation time is totally under our control and is accomplished through cleaner, faster code and constantly improving our backend architectures.
Render time measures how much time the user's web browser needs to process a response from Facebook and display the resultant web page. Like network time, we are somewhat constrained here by the performance and behavior of the various browsers but much is still under our control. The less we send back to the user, the faster the browser can display results, so minimizing bytes of HTML, CSS, JavaScript, and images also helps with render time. Another simple way to reduce render time is to execute as little JavaScript as possible before showing the page to the user.
The three metrics I describe are effective at capturing individual components of user perceived performance, but we wanted to roll them up into one number that would give us a high level sense of how fast the site is. We call this metric Time-to-Interact (TTI for short), and it is our best sense of how long the user has to wait for the important contents of a page to become visible and usable. On our homepage, for example, TTI measures the time it takes for the newsfeed to become visible.

First Steps


From early 2008 to mid 2009, we spent a lot of time following the best practices laid out by pioneers in the web performance field to try and improve TTI. For anyone serious about making a web site faster, Steve Souders's compilations are must-reads: High Performance Web Sitesand Even Faster Web Sites. We also developed some impressive technologies of our own to measure and improve the performance of Facebook as described at the 2009 O’Reilly Velocity Conference by two Facebook engineers, David Wei and Changhao Jiang.
By June of 2009 we had made significant improvements, cutting median render time in half for users in the United States. This was great progress, but in the meantime, Facebook had exploded in popularity all across the globe and we needed to start thinking about a worldwide audience. We decided to measure TTI at the 75th percentile for all users as a better way to represent how fast the site felt. After looking at the data, we set an ambitious goal to cut this measurement in half by 2010; we had about six months to make Facebook twice as fast.

Six Months and Counting...


On closer inspection, our measurements told us that pages were primarily slow because of network and render time. Our generation time definitely had (and still has) significant room to improve but it wouldn't provide the same bang for the buck. So we devoted most of our engineering effort towards two goals: drastically cutting down the bytes of cookies, HTML, CSS, and JavaScript required by a Facebook page while also developing new frameworks and methodologies that would allow the browser to show content to the user as quickly as possible.
Cutting back on cookies required a few engineering tricks but was pretty straightforward; over six months we reduced the average cookie bytes per request by 42% (before gzip). To reduce HTML and CSS, our engineers developed a new library of reusable components (built on top of XHP) that would form the building blocks of all our pages. Before the development of this component library, each page would rely on a lot of custom HTML and CSS even though many pages shared similar features and functionality. With the component library, it’s easy to optimize our HTML in one place and see it pay off all across the site. Another benefit is that, since the components share CSS rules, once a user has downloaded some CSS it’s very likely those rules will be reused on the next page instead of needing to download an entirely new set. Due to these efforts, we cut our average CSS bytes per page by 19% (after gzip) and HTML bytes per page by 44% (before gzip). These dramatic reductions mean we get our content to users faster and browsers can process it more quickly.
Cutting back on JavaScript was another challenging problem. Facebook feels like a dynamic and engaging site in large part due to the JavaScript functionality we've created, but as we added more and more features, we wrote more and more JavaScript which users have to download to use the site. Remember that downloading and executing JavaScript are two of the main issues we need to combat to improve network and render time. To address this problem our engineers took a step back and looked at what we were using JavaScript to accomplish. We noticed that a relatively small set of functionality could be used to build a large portion of our features yet we were implementing them in similar-but-different ways. This common functionality could be provided in a very small, efficient library that is also cacheable on the user's computer. We set out to rewrite our core interactions on top of this new library, called Primer, and saw a massive 40% decrease (after gzip) in average JavaScript bytes per page. Since Primer is downloaded quickly and then cached for use on future page views, it also means that features built exclusively on Primer are immediately usable when they appear on the screen; there's no need to wait for further JavaScript to download. An example of such a feature is our feedback interface which allows users to comment on, like, and share content and appears all across Facebook.
Another project I'd like to highlight requires a little more setup. As described earlier, the traditional model for loading a web page involves a user sending a request to a server, the server generating a response which is sent back to the browser, and the browser converting the response in to something the user can see and interact with. If you think about this model there is a glaring problem. Let's say it takes a few hundred milliseconds for the server to completely prepare and send a response back to the user. While the server is chugging through its work the browser is just sitting there uselessly, waiting for something to do and generally being lazy. What if we could pipeline this whole procedure? Wouldn't it be great if the server could do a little bit of work, say in ten or fifty milliseconds, and then send a partial response back to the browser which can then start downloading JavaScript and CSS or even start displaying some content? Once the server has done some more processing and has produced another bit of output it can send that back to the browser as well. Then we just repeat the process until the server has nothing left to do. We've overlapped a significant portion of the generation time with the render time which will reduce the overall TTI experienced by the user.
Over the last few months we've implemented exactly this ability for Facebook pages. We call the whole system BigPipe and it allows us to break our web pages up in to logical blocks of content, called Pagelets, and pipeline the generation and render of these Pagelets. Looking at the home page, for example, think of the newsfeed as one Pagelet, the Suggestions box another, and the advertisement yet another. BigPipe not only reduces the TTI of our pages but also makes them seem even faster to users since seeing partial content earlier feels faster than seeing complete content a little bit later.

Success!


I'm pleased to say that on December 22nd, as a result of these and other efforts, we declared victory on our goal to make the site twice as fast. We even had 9 whole days to spare!

After hitting the 2x site speed goal the team celebrated with t-shirts. And dinner (not pictured).

I hope that you've personally experienced and appreciated the improvements we've made in site speed and that this post has given you some insight in to how we think about and approach performance projects at Facebook. Stay tuned for more details on many of the projects I mention here in future blog posts and industry conferences. In 2010 look for the site to get even faster as we tackle new challenges!
Jason, an engineer at Facebook, wants to remind you that perf graphs go the wrong way.

Como fazer cópia de segurança dos posts do blog

Posted by Mr.Editor Saturday, February 20, 2010 1 comments

 image

Neste post mostra-se como fazer cópia de segurança dos posts do blog. Pode exportar o seu blogue para o formato de exportação Blogger Atom. Pode fazê-lo para mover o seu blogue para outro serviço de blogues ou apenas para o armazenar no disco rígido. O seu blogue não será alterado, continuando online como antes.

  1. Entre no blog em www.blogger.com
  2. Clique em Definições e depois em Básico
  3. Clique em Exportar blogue

  4. image

    Clique em TRANSFERIR BLOGUE e depois, na janela de diálogo, seleccione Guardar para ficheiro (Save to file), clique em OK e escolha o nome do ficheiro onde ficará guardado o blogue.

 

Fácil, não é? Desta forma, se perder o acesso ao blogue, não perde os conteúdos.

Note que são guardados os posts, os comentários e as etiquetas dos posts.

 

Tendo o blog guardado, pode criar um novo blog e para ele transferir os posts, comentários e etiquetas que antes tinha guardado. Para isso clique em Importar blogue e siga as instruções.

 

Leitura adicional: How do I import and export blogs on Blogger?

Como adicionar o seu site ou blog ao Buzz

Posted by Mr.Editor Friday, February 19, 2010 1 comments

O Google associa a maior parte dos seus blogs à sua conta Google. Estes podem ser adicionados ao seu Buzz clicando em no link "Connected Sites" ao lado do seu perfil:

clip_image002

Desta forma, os seus blog posts são automaticamente adicionados ao Buzz.

Mas como fazer se o blog ou site a conectar não estiver na lista "Connect more sites"? Neste caso, siga estas instruções:

  1. Faça uma cópia de segurança da template (ver aqui como)
  2. edite a sua template e procure o texto </head>
  3. abra uma linha por cima e adicione o seguinte texto

    <link rel="me" type="text/html" href="http://www.google.com/profiles/profilename"/>

    nota: substitua profilename pelo perfil da sua conta Google.
  4. Grave a template
  5. Vá a https://sgapi-recrawl.appspot.com/ e clique em Recrawl

    nota: se o site pretendido não estiver nesta lista, terá que aguardar uns dias até que o robot do Google volte a passar no seu site
  6. Volte ao Buzz e clique no link "connected sites" e adicione os que novos sites

F*ck You, Google

Posted by Mr.Editor 0 comments

Um texto interessante sobre a questão da privacidade do Google Buzz (destaques meus). É de notar que há uma diferença fundamental aderir livremente a uma rede social, como se pode fazer com o Facebook e tantas outras, ou ser incluído sem permissão prévia numa delas, como fez a Google. A tecnologia do Buzz é muito interessante mas a atitude da Google é imperdoável.

F*ck You, Google

I use my private Gmail account to email my boyfriend and my mother. There's a BIG drop-off between them and my other "most frequent" contacts. You know who my third most frequent contact is. My abusive ex-husband.

Which is why it's SO EXCITING, Google, that you AUTOMATICALLY allowed all my most frequent contacts access to my Reader, including all the comments I've made on Reader items, usually shared with my boyfriend, who I had NO REASON to hide my current location or workplace from, and never did.

My other most frequent contacts? Other friends of Flint's.

Oh, also, people who email my ANONYMOUS blog account, which gets forwarded to my personal account. They are frequent contacts as well. Most of them, they are nice people. Some of them are probably nice but a little unbalanced and scary. A minority of them - but the minority that emails me the most, thus becoming FREQUENT - are psychotic men who think I deserve to be raped because I keep a blog about how I do not deserve to be raped, and this apparently causes the Hulk rage.

I can't block these people, because I never made a Google profile or Buzz profile, due to privacy concerns (apparently and resoundingly founded!). Which doesn't matter anyway, because every time I do block them, they are following me again in an hour. I'm hoping that they, like me, do not realize and are not intentionally following me, but that's the optimistic half of the glass. My pessimistic half is of the abyss, and it is staring back at you with a redolent stink-eye.

Oh, yes, I suppose I could opt out of Buzz - which I did when it was introduced, though that apparently has no effect on whether or not I am now using Buzz - but as soon as I did that, all sorts of new people were following me on my Reader! People I couldn't block, because I am not on Buzz!

Fuck you, Google. My privacy concerns are not trite. They are linked to my actual physical safety, and I will now have to spend the next few days maintaining that safety by continually knocking down followers as they pop up. A few days is how long I expect it will take before you either knock this shit off, or I delete every Google account I have ever had and use Bing out of fucking spite.

Fuck you, Google. You have destroyed over ten years of my goodwill and adoration, just so you could try and out-MySpace MySpace.

 

 

Harriet Jacobs is the nom de plume of the author of Fugitivus. She's a mid-twenties white girl living in the Midwest, working at a non-profit that assists families and deals with a lot of racial politics. Harriet has had a fucked-up life, and Fugitivus
—fugitive—is her space to talk, where the fucked-up people who did the fucked-up things couldn't find her and be creepy.

Bad Valentine is our own special take on the beauty—and awkwardness—of geek love.

Update: The original blog posting has been updated and made private.

The author of this post can be contacted at tips@gizmodo.com

Software projects Os projectos de software, como quaisquer outros, por vezes falham. Projectos de longa duração (anos) e de maior dimensão têm maior risco de serem cancelados. E é precisamente quando o prazo de conclusão se aproxima que a decisão acaba por se colocar em cima a mesa: vale a pena investir mais uma pipa de dinheiro num projecto que não vai estar concluído no prazo esperado ou para o qual as funcionalidades serão substancialmente diferentes daquelas que se havia projectado? Esse é o momento em que se faz mais um esforço ou em que se decide secar o sorvedouro. A título de exemplo, estatísticas mostram que os projectos com pleno sucesso (terminados no prazo e dentro do orçamento) andarão pela casa de apenas 30%.

O artigo no fim deste texto, em inglês, é uma interessante dissertação sobre o tema. Entre os factores de falha apontados no artigo, estes são destacados:

  • Objectivos irrealistas ou desarticulados para o projecto
  • Inadequada estima dos recursos necessários
  • Requisitos de sistema mal definidos
  • Informação deficiente quanto ao estado do projecto
  • Riscos não geridos
  • Comunicação deficiente entre cliente, implementadores e utilizadores
  • Uso de tecnologia imatura
  • Incapacidade para gerir a complexidade do projecto
  • Práticas de desenvolvimento desleixadas
  • Deficiente gestão de projecto
  • Parceiros de negócio políticos
  • Pressões comerciais
Vem esta conversa a propósito do anuncio do governo em gastar 15 milhões de euros num projecto de software para o Ministério da Educação e em gastar outros 15 milhões na manutenção operacional deste software durante quatro anos.

15 milhões para desenvolver um projecto de software é uma pipa de dinheiro. Para se ter uma percepção, uma pesquisa no Google devolve alguns exemplos que permitem contextualizar esta grandeza (para simplificação, asumo 1€ = $1USD). Ver por exemplo este, este e este. Ou visto ainda de outra forma, 15 milhões de euros daria para manter uma equipa de cerca 100 pessoas a trabalhar durante dois anos, com cada membro da equipa a "ganhar" 6000 € brutos (valor bruto para incluir impostos, despesas de funcionamento e lucro do negócio). É mesmo um negócio-lotaria.

Assim sendo, supõe-se que as melhores práticas tenham sido usadas para definir os objectivos do projecto, minimizando desde logo o primeiro dos riscos da lista anterior. Supõem-se igualmente que se tenha elaborado um bom caderno de encargos e que este tenha sido apresentado a concurso, para assim se obter a melhor solução.

Não. Nada disto foi feito. Pelo contrário, o governo decidiu gastar uma página A4 do Diário da República em propaganda e optou por entregar um projecto desta dimensão por ajuste directo. Quais são os objectivos do projecto? Não se sabe. Apenas foi publicada uma descrição lacónica.

A questão aqui está em não ser possível saber se 15 milhões de euros é muito ou pouco para o projecto em causa. Pela simples razão de não se saber o que se pretende construir. Apenas sabemos, como vimos,que um valor desta grandeza corresponde um projecto de dimensão considerável. Portanto, ainda mais espanta a leviandade na sua definição.

Mais surpreendente do que o valor do projecto de desenvolvimento são os 15 milhões de euros para gastar durante quatro anos em manutenção operacional do projecto. São mais de 10 mil euros por dia durante quatro anos (365 dias por ano). Que produção tão astronómica vai ser então produzida diariamente? Não se sabe.

Na anterior lista de riscos que levam os projectos a falhar hão-de ser poucos os que não se venha a concretizar neste projecto. É isto a visão Simplex deste governo?


Artigo: Why Software Fails

Why Software Fails
By Robert N. Charette
First Published September 2005

We waste billions of dollars each year on entirely preventable mistakes
Have you heard the one about the disappearing warehouse? One day, it vanished—not from physical view, but from the watchful eyes of a well-known retailer's automated distribution system. A software glitch had somehow erased the warehouse's existence, so that goods destined for the warehouse were rerouted elsewhere, while goods at the warehouse languished. Because the company was in financial trouble and had been shuttering other warehouses to save money, the employees at the "missing" warehouse kept quiet. For three years, nothing arrived or left. Employees were still getting their paychecks, however, because a different computer system handled the payroll. When the software glitch finally came to light, the merchandise in the warehouse was sold off, and upper management told employees to say nothing about the episode.

This story has been floating around the information technology industry for 20-some years. It's probably apocryphal, but for those of us in the business, it's entirely plausible. Why? Because episodes like this happen all the time. Last October, for instance, the giant British food retailer J Sainsbury PLC had to write off its US $526 million investment in an automated supply-chain management system. It seems that merchandise was stuck in the company's depots and warehouses and was not getting through to many of its stores. Sainsbury was forced to hire about 3000 additional clerks to stock its shelves manually [see photo, "Market Crash"]

This is only one of the latest in a long, dismal history of IT projects gone awry [see table, "Software Hall of Shame" for other notable fiascoes]. Most IT experts agree that such failures occur far more often than they should. What's more, the failures are universally unprejudiced: they happen in every country; to large companies and small; in commercial, nonprofit, and governmental organizations; and without regard to status or reputation. The business and societal costs of these failures—in terms of wasted taxpayer and shareholder dollars as well as investments that can't be made—are now well into the billions of dollars a year.

The problem only gets worse as IT grows ubiquitous. This year, organizations and governments will spend an estimated $1 trillion on IT hardware, software, and services worldwide. Of the IT projects that are initiated, from 5 to 15 percent will be abandoned before or shortly after delivery as hopelessly inadequate. Many others will arrive late and over budget or require massive reworking. Few IT projects, in other words, truly succeed.

The biggest tragedy is that software failure is for the most part predictable and avoidable. Unfortunately, most organizations don't see preventing failure as an urgent matter, even though that view risks harming the organization and maybe even destroying it. Understanding why this attitude persists is not just an academic exercise; it has tremendous implications for business and society.

SOFTWARE IS EVERYWHERE. It's what lets us get cash from an ATM, make a phone call, and drive our cars. A typical cellphone now contains 2 million lines of software code; by 2010 it will likely have 10 times as many. General Motors Corp. estimates that by then its cars will each have 100 million lines of code.

The average company spends about 4 to 5 percent of revenue on information technology, with those that are highly IT dependent—such as financial and telecommunications companies—spending more than 10 percent on it. In other words, IT is now one of the largest corporate expenses outside employee costs. Much of that money goes into hardware and software upgrades, software license fees, and so forth, but a big chunk is for new software projects meant to create a better future for the organization and its customers.

Governments, too, are big consumers of software. In 2003, the United Kingdom had more than 100 major government IT projects under way that totaled $20.3 billion. In 2004, the U.S. government cataloged 1200 civilian IT projects costing more than $60 billion, plus another $16 billion for military software.

Any one of these projects can cost over $1 billion. To take two current examples, the computer modernization effort at the U.S. Department of Veterans Affairs is projected to run $3.5 billion, while automating the health records of the UK's National Health Service is likely to cost more than $14.3 billion for development and another $50.8 billion for deployment.

Such megasoftware projects, once rare, are now much more common, as smaller IT operations are joined into "systems of systems." Air traffic control is a prime example, because it relies on connections among dozens of networks that provide communications, weather, navigation, and other data. But the trick of integration has stymied many an IT developer, to the point where academic researchers increasingly believe that computer science itself may need to be rethought in light of these massively complex systems.

When a project fails, it jeopardizes an organization's prospects. If the failure is large enough, it can steal the company's entire future. In one stellar meltdown, a poorly implemented resource planning system led FoxMeyer Drug Co., a $5 billion wholesale drug distribution company in Carrollton, Texas, to plummet into bankruptcy in 1996.

IT failure in government can imperil national security, as the FBI's Virtual Case File debacle has shown. The $170 million VCF system, a searchable database intended to allow agents to "connect the dots" and follow up on disparate pieces of intelligence, instead ended five months ago without any system's being deployed [see "Who Killed the Virtual Case File?" in this issue].

IT failures can also stunt economic growth and quality of life. Back in 1981, the U.S. Federal Aviation Administration began looking into upgrading its antiquated air-traffic-control system, but the effort to build a replacement soon became riddled with problems [see photo, "Air Jam"]. By 1994, when the agency finally gave up on the project, the predicted cost had tripled, more than $2.6 billion had been spent, and the expected delivery date had slipped by several years. Every airplane passenger who is delayed because of gridlocked skyways still feels this cancellation; the cumulative economic impact of all those delays on just the U.S. airlines (never mind the passengers) approaches $50 billion.

Worldwide, it's hard to say how many software projects fail or how much money is wasted as a result. If you define failure as the total abandonment of a project before or shortly after it is delivered, and if you accept a conservative failure rate of 5 percent, then billions of dollars are wasted each year on bad software.

For example, in 2004, the U.S. government spent $60 billion on software (not counting the embedded software in weapons systems); a 5 percent failure rate means $3 billion was probably wasted. However, after several decades as an IT consultant, I am convinced that the failure rate is 15 to 20 percent for projects that have budgets of $10 million or more. Looking at the total investment in new software projects—both government and corporate—over the last five years, I estimate that project failures have likely cost the U.S. economy at least $25 billion and maybe as much as $75 billion.

Of course, that $75 billion doesn't reflect projects that exceed their budgets—which most projects do. Nor does it reflect projects delivered late—which the majority are. It also fails to account for the opportunity costs of having to start over once a project is abandoned or the costs of bug-ridden systems that have to be repeatedly reworked.

Then, too, there's the cost of litigation from irate customers suing suppliers for poorly implemented systems. When you add up all these extra costs, the yearly tab for failed and troubled software conservatively runs somewhere from $60 billion to $70 billion in the United States alone. For that money, you could launch the space shuttle 100 times, build and deploy the entire 24-satellite Global Positioning System, and develop the Boeing 777 from scratch—and still have a few billion left over.

Why do projects fail so often »

Among the most common factors:

* Unrealistic or unarticulated project goals
* Inaccurate estimates of needed resources
* Badly defined system requirements
* Poor reporting of the project's status
* Unmanaged risks
* Poor communication among customers, developers, and users
* Use of immature technology
* Inability to handle the project's complexity
* Sloppy development practices
* Poor project management
* Stakeholder politics
* Commercial pressures

Of course, IT projects rarely fail for just one or two reasons. The FBI's VCF project suffered from many of the problems listed above. Most failures, in fact, can be traced to a combination of technical, project management, and business decisions. Each dimension interacts with the others in complicated ways that exacerbate project risks and problems and increase the likelihood of failure.

Consider a simple software chore: a purchasing system that automates the ordering, billing, and shipping of parts, so that a salesperson can input a customer's order, have it automatically checked against pricing and contract requirements, and arrange to have the parts and invoice sent to the customer from the warehouse.

The requirements for the system specify four basic steps. First, there's the sales process, which creates a bill of sale. That bill is then sent through a legal process, which reviews the contractual terms and conditions of the potential sale and approves them. Third in line is the provision process, which sends out the parts contracted for, followed by the finance process, which sends out an invoice.

Let's say that as the first process, for sales, is being written, the programmers treat every order as if it were placed in the company's main location, even though the company has branches in several states and countries. That mistake, in turn, affects how tax is calculated, what kind of contract is issued, and so on.

The sooner the omission is detected and corrected, the better. It's kind of like knitting a sweater. If you spot a missed stitch right after you make it, you can simply unravel a bit of yarn and move on. But if you don't catch the mistake until the end, you may need to unravel the whole sweater just to redo that one stitch.

If the software coders don't catch their omission until final system testing—or worse, until after the system has been rolled out—the costs incurred to correct the error will likely be many times greater than if they'd caught the mistake while they were still working on the initial sales process.

And unlike a missed stitch in a sweater, this problem is much harder to pinpoint; the programmers will see only that errors are appearing, and these might have several causes. Even after the original error is corrected, they'll need to change other calculations and documentation and then retest every step.

In fact, studies have shown that software specialists spend about 40 to 50 percent of their time on avoidable rework rather than on what they call value-added work, which is basically work that's done right the first time. Once a piece of software makes it into the field, the cost of fixing an error can be 100 times as high as it would have been during the development stage.

If errors abound, then rework can start to swamp a project, like a dinghy in a storm. What's worse, attempts to fix an error often introduce new ones. It's like you're bailing out that dinghy, but you're also creating leaks. If too many errors are produced, the cost and time needed to complete the system become so great that going on doesn't make sense.

In the simplest terms, an IT project usually fails when the rework exceeds the value-added work that's been budgeted for. This is what happened to Sydney Water Corp., the largest water provider in Australia, when it attempted to introduce an automated customer information and billing system in 2002 [see box, "Case Study #2"]. According to an investigation by the Australian Auditor General, among the factors that doomed the project were inadequate planning and specifications, which in turn led to numerous change requests and significant added costs and delays. Sydney Water aborted the project midway, after spending AU $61 million (US $33.2 million).

All of which leads us to the obvious question: why do so many errors occur?

Software project failures have a lot in common with airplane crashes. Just as pilots never intend to crash, software developers don't aim to fail. When a commercial plane crashes, investigators look at many factors, such as the weather, maintenance records, the pilot's disposition and training, and cultural factors within the airline. Similarly, we need to look at the business environment, technical management, project management, and organizational culture to get to the roots of software failures.

Chief among the business factors are competition and the need to cut costs. Increasingly, senior managers expect IT departments to do more with less and do it faster than before; they view software projects not as investments but as pure costs that must be controlled.

Political exigencies can also wreak havoc on an IT project's schedule, cost, and quality. When Denver International Airport attempted to roll out its automated baggage-handling system, state and local political leaders held the project to one unrealistic schedule after another. The failure to deliver the system on time delayed the 1995 opening of the airport (then the largest in the United States), which compounded the financial impact manyfold.

Even after the system was completed, it never worked reliably: it chewed up baggage, and the carts used to shuttle luggage around frequently derailed. Eventually, United Airlines, the airport's main tenant, sued the system contractor, and the episode became a testament to the dangers of political expediency.

A lack of upper-management support can also damn an IT undertaking. This runs the gamut from failing to allocate enough money and manpower to not clearly establishing the IT project's relationship to the organization's business. In 2000, retailer Kmart Corp., in Troy, Mich., launched a $1.4 billion IT modernization effort aimed at linking its sales, marketing, supply, and logistics systems, to better compete with rival Wal-Mart Corp., in Bentonville, Ark. Wal-Mart proved too formidable, though, and 18 months later, cash-strapped Kmart cut back on modernization, writing off the $130 million it had already invested in IT. Four months later, it declared bankruptcy; the company continues to struggle today.

Frequently, IT project managers eager to get funded resort to a form of liar's poker, overpromising what their project will do, how much it will cost, and when it will be completed. Many, if not most, software projects start off with budgets that are too small. When that happens, the developers have to make up for the shortfall somehow, typically by trying to increase productivity, reducing the scope of the effort, or taking risky shortcuts in the review and testing phases. These all increase the likelihood of error and, ultimately, failure.

A state-of-the-art travel reservation system spearheaded by a consortium of Budget Rent-A-Car, Hilton Hotels, Marriott, and AMR, the parent of American Airlines, is a case in point. In 1992, three and a half years and $165 million into the project, the group abandoned it, citing two main reasons: an overly optimistic development schedule and an underestimation of the technical difficulties involved. This was the same group that had earlier built the hugely successful Sabre reservation system, proving that past performance is no guarantee of future results.

 

Inicialmente publicado a 21-05-2009

Nota: com este texto termina a série de republicações.

5 dicas para melhor aproveitar o Google Buzz

Posted by Mr.Editor Thursday, February 18, 2010 0 comments

Depois do estrondo que foi o Google Buzz, é a vez da Microsoft apanhar o comboio, com o  Microsoft Outlook 2010.

image

Detalhes no blog do Miscroft Outlook: Announcing the Outlook Social Connector.

O Linkedin, rede social mais vocacionada para o mercado de emprego, já disponibiliza no seu site um conector para esta nova funcionalidade.

Web PC

Posted by Mr.Editor 2 comments

image Quanto a este novo fôlego na guerra dos browsers, abriu JCD do blog Blasfémias a discussão com o post "Competição a Zero €uros".

Sobre o tema em questão, há sem dúvida muito dinheiro evolvido. Com a largura de banda a aumentar regularmente e com o advento do DSL (ou ADSL para os "pobres"), a computação distribuída ganhou novo fôlego. Do servidor central com terminais passámos para a informática pessoal do PC. Um notável percurso que culminou com o domínio da Microsoft graças a estratégias diversas - e nem todas de cariz tecnológico. No universo Windows o consumidor, perdão, o utilizador, compra uma máquina e licenças de utilização dum conjunto completo de software, desde o sistema operativo até aos pacotes de produtividade. O core businesses da Microsoft reside precisamente nesta particularidade de se estar agarrado à plataforma pelo sistema operativo e pelas suas aplicações.

Neste ponto entra em jogo o factor "Internet & banda larga". Estas ligações em rede, cada vez mais rápida e de maior capacidade, permitem voltar ao conceito do servidor com os seus terminais. Excepto que estes, contrariamente aos primeiros, não são "estúpidos" - têm capacidade de processamento local. Este facto aliado à ligação em rede traz um novo conceito de computação para a generalidade dos utilizadores, sendo a peça chave o software que permita integrar a capacidade de processamento local com a do servidor à qual se está ligado em rede e que, até ao momento tem sido o browser.

O Google Chrome não é apenas mais um browser. Constitui a entrada dum novo actor num momento de mudança de paradigma. Opções tecnológicas, descritas num anterior texto, como um site web corresponder a um processo, a existência duma framework para alargar as funcionalidades do browser e o suporte à comunidade de programadores indicam que o Chrome poderá vir a constituir uma nova plataforma aplicacional. Em vez de se desenvolverem aplicações para Windows, Mac ou Linux, desenvolvem-se para o Chrome . Não importa que máquina e que sistema operativo está o utilizador a usar. Basta que corra o Chrome e tenha ligação à net.

Em certa medida, os actuais browsers já são usados como plataformas aplicacionais mas apenas para áreas específicas. O lucrativo feudo das aplicações de produtividade como processamento de texto, imagem, dados, etc. ainda é praticamente exclusivo ao tradicional software para computador pessoal. Quem quiser entrar e vencer neste mercado tem que fazer melhor e mais barato do que a concorrência. E mesmo assim não tem garantido o sucesso. Vejam-se os casos do OpenOffice (gratuito) e do StarOffice (cerca de 70 dólares) que são funcionalmente equivalentes ao Microsoft Office, mais baratos, compatíveis até ao nível do formato de documentos (até a Microsoft ter mudado e patenteado um novo formato de ficheiros no Office XP) e, no entanto, estas aplicações não arrasaram o mercado da Microsoft.

Com a computação distribuída que a web actualmente permite, as empresas de software deixam de ter que competir no terreno Microsoft. Por outro lado, os utilizadores deixam de estar agarrados ao sistema operativo e às suas aplicações específicas. Talvez fiquem agarrados ao browser ou à nova plataforma que o substitua. Mas, garantidamente, deixam de estar dependentes dum sistema e das suas aplicações.

Esta mudança é substancial, comparável à mudança do MS-DOS para Windows. O Wordperfect perdeu para o Microsoft Office. Veremos a repetição do dono da nova plataforma conseguir impor o seu pacote aplicacional como o standard de mercado? É um caso a seguir, até porque a concorrência não dorme.

 

Publicado originalmente a 11-09-2008

Imagem: Linutop touts tiny diskless Linux web PC (artigo de Nov. 2006)

Digital Rights Management

Posted by Mr.Editor Wednesday, February 17, 2010 0 comments

Um excelente artigo sobre Digital Rights Management (DRM):

How to break DRM (iTunes, DVD, etc) for lawful purposes

(copying for back-up, transcoding into different devices)

This page was written with non-techie people in mind. If you read SlashDot or BoingBoing, if you're active in the anti-DRM movement, etc, then this page will have nothing new for you. But if you are an "average computer user", then you probably think that breaking DRM is too hard, too complicated, impossible, or illegal. This page is for you.

 

9 anos de Google

Posted by Mr.Editor 1 comments

Ora aí está, 9 anos a googlar. Entre nós não é costume mas no inglês da América é prática corrente construir novos verbos a partir de substantivos (É curioso, não seria capaz de dizer isto usando a TLEBS!) Assim, no contexto anglo-saxónico, "to google" é equivalente a pesquisar. Até existe uma entrada na Wikipedia sobre este assunto: link.

Estava na faculdade quando isto do serviço Internet www começou a fervilhar entre a comunidade universitária. "Ir à net" era então uma expressão inexistente, mas existindo significaria ir até ao laboratório da faculdade, utilizar uma estação de trabalho Sun e, usando o Netscape, e consultar uma ou outra página nova, já que as existentes raramente eram actualizadas.

 

Recordo-me perfeitamente dum colega que tinha encontrado a página pessoal - era assim que eram chamadas as páginas web - onde o autor mantinha uma lista de endereços favoritos. Na altura já ia em centenas! Estas páginas terão sido os primeiros portais. Alguém lhes antecipava a importância que viriam a ter? Eu não, infelizmente. No entanto houve que visse esse potencial e apostasse forte. Yahoo, Infoseek, Altavista e vários outros foram desbravando o caminho. O Google foi dos últimos a chegar e triunfou graças à velocidade com que devolvia os resultados e à capacidade em apresentar resultados relevantes, com o algoritmo PageRank (link).

Curiosamente, foi também graças a este algoritmo que sugiram as chamadas Google Bombs (link). Consiste em diferentes páginas web conterem uma frase igual a apontar para um mesmo endereço. Na campanha eleitoral de Bush em 2004, o termo "miserable failure" foi usando sistematicamente como texto do link para página da biografia de GWBush. Assim, uma pesquisa com estes termos enganava o algoritmo do Google e uma página não relacionada aparecia no topo dos resultados.

 

Nove anos depois, esta empresa continua a inovar em grande escala e, neste momento, é o rival da Microsoft, com reais possibilidades de lhe fazer o que ela havia feito à IBM: destrona-la do lugar de nº 1 da informática mundial. E o infortúnio, para a Microsoft, acontece pela mudança de paradigma. Tal como o mainframe, o servidor central, foi destronado graças ao computador pessoal, também o conceito "um sistema operativo+um conjunto de aplicações=um utilizador", ganha pão da Microsoft, se tornará obsoleto perante o reaparecer do conceito dum servidor central e múltiplos clientes a ele ligados. Isto está a tornar-se possível graças ao ADSL e as suas crescentes velocidades de ligação.

A Microsoft, claro, não está a dormir e já lançou o serviço Windows Live, cópia chapada dos serviços do Google. Mas este sinal é precisamente o pronuncio do fim, em que o líder passa a seguir a concorrência, em vez do contrário. Vamos ver se, como no Triunfo dos Porcos, apenas se troca um dominador por outro, até tendo este a particularidade de querer saber tudo sobre todos.

Publicado inicialmente a 27-09-2007

Ainda a recuperar textos antigos

Posted by Mr.Editor Tuesday, February 16, 2010 0 comments

Acabo de republicar os textos relativos ao iPad. Tenho mais uns quantos que valem a republicação, sobretudo sobre software, que sairão diariamente às 7h00, para não saturar o blog.

image Um artigo de Charlie Brooker escrito com humor sobre o iPad. Deixo uma tradução caseira de algumas partes:

iPad therefore iWant? Probably. Why? iDunno

Numa primeira impressão parece um iPhone numa forma não manuseável e fora do tamanho de bolso. Mas olhe-se mais demoradamente e.... Não. Tinha-se razão na primeira vez.

(...)

O iPad fica entre dois conceitos - não é bem um laptop e não é bem um smartphone. Por outras palavras, é o utilitário do consumidor de bens electrónicos. Ou seria, não fosse um factor crucial: parece ideal para navegar na net enquanto se vê televisão. E suspeito que para isso será usado maioritariamente. Milhões de pessoas vêem TV enquanto consultam os seus emails: é a combinação perfeita para elas.

(...)

Algumas pessoas queixam-se que não tem uma câmara. Que tecno-bebés mimados. Lá porque uma coisa é tecnologicamente possível, isso não significa que tenha que ser feita. É tecnologicamente possível fazer uma batedeira de ovos que faça chamadas, um leitor de MP3 que doseie salgadinhos ou um carro com pára-brisas de pão. A humanidade continuará a prosperar na sua ausência. Nem tudo precisa de uma lente de 15 megapixéis espetada nas traseiras, tal como um pequeno ânus de vidro. Dêem a estes ingratos uma câmara e eles choramingarão que não tinha uma segunda câmara incluída. O que é que estão a fotografar, já agora? A vossa colecção de câmaras?

(...)

Quanto a mim, não tenho a certeza que compre um iPad, embora me pareça - me pareça - que estou para comprar um MacBook.

(...)

Passada a euforia da revelação, eis que chega o momento de uma análise dos pontos negativos do iPad.

  • Sem USB e sem leitor de cartões, fazer entrar dados* no aparelho fica mais complicado. Pode-se comprar adaptadores que permitirão transformar o conector de 30 pinos em USB, leitor de cartões SD ou carregador da bateria. Mas francamente, longe ficará a expectativa de se ter um computador portátil.
    image
    Na imagem: a base para o iPad; os adaptadores para USB e para SD; o adaptador para carregar a bateria.
    *fotos, documentos, música, vídeo, etc.
    Imagine-se por exemplo um fotografo em trabalho de campo. Levaria a sua bela D-SLR e o iPad. Depois de fotografar, transferiria as fotos para o iPad para as visualizar e, eventualmente publicar. Assim para o fazer terá que comprar mais uma geringonça.
  • Não tem câmara pelo que não pode ser usado para vídeo-conferência. Nem para colocar uns clips no Youtube.
  • Não corre mais do que uma aplicação de cada vez, dado que o sistema operativo não é multitasking (multi-tarefa). Por exemplo, ao escrever-se um texto no "Pages" (o processador de texto incluído) se se quiser copiar um pedaço de texto do browser, ter-se-á que fechar o "Pages", abrir o browser para copiar o texto e voltar ao "Pages" para colar o texto copiado. Pela mesma razão, não se pode ouvir música enquanto se trabalha noutra coisa. De facto, esta particularidade é bem mais limitativa do que o USB/SD. É ridículo que um computador (?) não tenha multi-tarefa nos dias de hoje.
  • O browser não suporta flash! Bye bye Youtube e mais uma carrada de sites que usem o flash player.
  • Quando o iPad está ligado à base (comprada à parte), ganha-se um porto USB. Um! Compre-se um hub USB se se quiser ligar mais do que um dispositivo ao mesmo  tempo. Isto admitindo que a Apple não restringiu o uso de hubs…

Apesar dos aspectos muito positivos (tamanho, ecrã táctil, autonomia, design), o facto é que opções de desenho do aparelho parecem querer torna-lo num iPhone com esteróides (como li algures) e sem concretizar o potencial que se lhe antevia em certos nichos de mercado. Estamos perante um Kindle a cores, ao que parece.

Num próximo texto, abordarei as alternativas ao iPad. Um cheirinho:

image

Pode-se dizer que o iPad (site oficial) parece um iPhone do tamanho A4 e com a performance de um computador portátil. Não tem teclado e o ecrã é sensível ao toque, tal como no iPhone. Traz de raiz a banda larga móvel 3G (depende do modelo).

Há um antes e um depois com este produto. Entrámos no depois.

Características

  • Dimensões e peso:  24.3 x 19.0 cm (altura x largura), 1.3 cm de espessura, 680 g de peso (modelo Wi-Fi) / 730 g (modelo Wi-Fi + 3G)
  • Ecrã: 24.6 cm (diagonal), 1024x768 pixéis a 132 ppi, resistente a dedadas,
  • Memória: Disco (solid state) de 16, 32 ou 64 GB
  • Processador: 1 GHz Apple A4
  • Wi-Fi: 802.11n
  • Banda larga móvel 3G (opcional) UMTS/HSDPA (850, 1900, 2100 MHz), só para dados
  • Bluetooth 2.1 + EDR
  • Autonomia da bateria: 10h
  • Inclui: altifalantes, microfone, conector de 30 pinos, acelerómetro e compasso.
  • Não inclui leitor de CD/DVD/Blue Ray!

Software

O iPad corre as aplicações do iPhone, o que é óptimo para quem já as tenha e mesmo para quem as queira comprar / usar (há-as gratuitas) pois já encontrará uma oferta aceitável de software (cerca de 140 mil aplicações). Como novidade, traz um calendário inovador (segundo a Apple), um aparentemente muito interessante gestor/visualizador de fotografias, toca música e passa filmes, vem com browser (Safari) para navegar na net, programa de mail, mapas  e traz um leitor de ebooks. Traz o software de desenho (Brushes) que tira partido da sensibilidade do ecrã. Mais detalhes aqui.

Preço

O modelo mais básico anunciado a 499 dólares! Os modelos com 3G custam mais 130 dólares.

image

Acessórios

Pode funcionar com teclado externo.

image

Comunicações

  • 3G, dependendo dos modelos modelos; Wi-Fi em todos
  • Nos EUA, e com a AT&T, 250MB de dados por mês custará 14.99 dólares e sem limite custará 29.99 dólares. Não será obrigatório contrato e poder-se-á cancelar o serviço 3G.
  • Nos EUA, a AT&T permite o uso gratuito de todos os seus pontos de Wi-Fi
  • A internacionalização ocorrerá em Junho ou Julho
  • Usa o USB para se sincronizar com o computador pessoal

Portanto, lá para as férias do Verão há brinquedo novo por estes lados.

Notícias relacionadas na imprensa nacional

Nota: este texto é essencialmente uma tradução adaptada deste, ao qual acrescei informação de fontes diversas

Google buzz

A Google decidiu entrar na senda das redes sociais. Fê-lo com o Google Buzz, passando por cima de todas as questões de privacidade dos seus utilizadores. Comecei por usar o Buzz no Fliscorno, para saber do que se trata e por o email do blogue não estar associado ao email pessoal. Sinceramente, é algo que não quero na minha conta pessoal. Vejo-lhe utilidade para a divulgação de conteúdos, tal como o Facebook ou o Twitter mas há uma diferença de nota: neste dois últimos, a adesão não é imposta. Pior, quem aderir ao Facebook ou ao Twitter sabe que o está a fazer numa rede onde as coisas serão públicas. Já com o Buzz, as pessoas aderiram com um certo nível de privacidade e este foi drasticamente alterado com a adição do Buzz. De um momento para o outro, passo a saber com quem outras pessoas trocam emails mais frequentemente, sem que elas tenham tido uma palavra no assunto. "Do no evil" é o slogam da Google. Certo...

 

Mas nestas coisas, cada qual sabe de si. Se o novo serviço da Google lhe agrada, tudo bem. Se não, segue-se um artigo que explica como desactivar o serviço. Num caso como noutro, convém é que saiba ao que está ;-)

February 11, 2010 10:01 AM PST

Buzz off: Disabling Google Buzz

by Jessica Dolcourt

 

Updated: February 11, 2010 at 12:15 p.m. PT to share a new rollout that Google implemented to better manage (and block) contacts. Also added a note about profile privacy.

Google Buzz logo

My colleague Molly Wood called it a privacy nightmare, but to many, Google's new social-networking tool Buzz is at its root an unwanted, unasked for pest. The way some of us see it, we didn't opt in to some newfangled Twitter system and we don't particularly want to see updates from contacts we never asked to follow creep up in our Buzz in-box. Call us what you will, but for curmudgeonly types like us, Buzz isn't so much social networking as it is socially awkward networking. We tried it, we didn't like it, and now it has to go.

Here's how we silenced Buzz from the desktop:

Step 0: Don't disable Buzz--yet

The automatic reaction is to scroll to the very bottom of Gmail and click the words "turn off buzz." But all this does is remove active links, leaving your profile still publicly available, along with any public buzzes you might have made while trying Buzz out. In fact, you're still technically following people, and they're following you. Not OK.

Buzz profile

Disabling Buzz isn't enough. My previous buzzes are still visible to anyone looking for them.

(Credit: Screenshot by Jessica Dolcourt/CNET)

Step 1: Purge your profile

One way to find your profile is to go to http://www.google.com/profiles and search on your name. Next, permanently delete buzzes in the public timeline by clicking the "Delete" tag. Then get to work unfollowing those that Google has "helped" you automatically follow.

Unfollow people on Buzz

From your profile, (1) click the hyperlink first and then (2) manually unfollow individuals.

(Credit: Screenshot by Jessica Dolcourt/CNET)

However, it's as if the Buzz team never envisioned anyone would want to completely opt out. You'll need to unfollow individuals one by one, which takes some time if Google subscribed you to a long list of followers. Despite what it said in our profile, we had to keep loading pages to unfollow a big chunk of friends.

Also take a moment to make sure that your profile isn't broadcasting anything you don't want it to. Click the "Edit Profile" link to the right of "Contacts" and "About me" to give your profile a once-over.

Note: If your profile was never public (and if you never experimented with Buzz), you'll have fewer privacy concerns. However, if you are getting rid of Buzz, it's a good idea to scan your profile to make sure you're not exposed on anyone's automatic list of followers.

Step 2: Block your followers

If you're serious about removing traces of yourself from Buzz's public record, you'll need to make sure you're invisible to others as well. Go back to Buzz in Gmail (if you already disabled it, you can turn Buzz back on at the bottom of the page to complete this step.) In the absence of an obvious "block all" button, we manually blocked each individual by clicking their picture from the list of followers and then selecting "Block."

Blocking people on Buzz

Blocking: Another option.

(Credit: Screenshot by Jessica Dolcourt/CNET)

At noon PT on Thursday, we noticed that Google rolled out a better interface that includes some management tools you can use to more easily block users. Prior to that, we noticed a few leftovers that were still visible in our public profile because we weren't previously able to access their profile tab. Thanks to Google's tweak, we unblocked them in a hurry.

Blocking someone won't alert them and you can always unblock them later if you change your mind about Buzz.

Better blocking in Buzz

A Thursday tweak adds drop-down tools to better manage followers.

(Credit: Screenshot by Jessica Dolcourt/CNET)

Step 3: Disable Buzz in Gmail

Now it's safe to disable Buzz in Gmail, thus removing the offending links and updates from your eyes.

Disable Gmail Buzz

Last step: Unplug Buzz in Gmail

(Credit: Screenshot by Jessica Dolcourt/CNET)

This worked for us, but leave your own tips and travails in the comments.

Related stories:
Rafe and Josh debate Google's Buzz
Google Buzz: Privacy nightmare
Google's social side hopes to catch some Buzz

Hitech Tips

Posted by Mr.Editor Monday, February 15, 2010 2 comments

É oficial, o blog Hitech Tips está no ar. Começa com uma séries de textos publicados noutros locais, aqui ficando reunidos (do mais antigo para o mais recente):

Este será um blog de cariz IT, orientado para as tecnologias da web. Como se pode ver na template, o inglês anda por estes lados. Com efeito, o blog não será escrito unicamente em português. Daqui para a frente haverá posts que sairão em inglês  e outros em inglês e português. Esta parte ainda não está bem decidia. Porquê a questão do inglês? Porque é a língua franca da informática e porque os artigos na forma de tutoriais são trabalhosos de fazer, daí procurar alargar a audiência.

Os contactos e demais informações estão na página About deste blog.

Boas blogagens.

Testar a performance do blog

É frequente ir-se adicionando coisas giras ao blog até que, a certo ponto, torna-se impossível abrir a página do blog. Acontece a muitos e aconteceu-me a mim. Nos últimos dias tem sido uma chatice abrir o blog desde que instalei os ícones para partilhar no facebook e no twitter. Depois de algumas experiências, conclui que o AddThis e o Tweetmeme entram em conflito, fazendo disparar o tempo de carregamento do blog dos 8 segundos para os 35 segundos! Optei por inibir, pelo menos temporariamente o AddThis.

Mas como cheguei a esta conclusão?


Instalei a ferramenta HttpWatch Basic Edition (freeware) e experimentei diversas combinações da template. Esta ferramenta mede o tempo de carregamento de uma página e mostra quanto tempo demora cada conteúdo a ser carregado.

image

A forma de funcionamento da ferramenta é algo fora do vulgar, já que corre integrada no browser. É conveniente ler o ficheiro "Getting Started", instalado com a aplicação, para ver como começar. Basicamente, no Firefox basta clicar no ícone no canto inferior direito:

image

e no Internet Explorer, clica-se no ícone equivalente existente na barra de ferramentas:

image

Dicas:

  1. em cada teste, carreguei em "Record" antes de refrescar a página e carreguei em "Stop" depois da página carregada (o ícone do browser pára de mexer), o que me permitiu ter as temporizações de cada página carregada.
  2. Testar no Internet Explorer é mais fácil, pois o Firefox abre vários canais de comunicação e fazer a soma do tempo gasto não é directo.
  3. Usar esta configuração quando se repetirem testes seguidos, pois facilita a comparação:
    image

Testar a velocidade da sua ligação à net

A segunda ferramenta não precisa de ser instalada. Basta aceder ao site

http://www.speedtest.net

e correr o teste. A imagem seguinte mostra o resultado da minha ligação:

image

Para comparação, a ferramenta mostra outros resultados. Por exemplo, para a Alemanha e Portugal, os quadros são os seguintes:

image

Fico a saber que a minha velocidade fica 60% das melhores ligações portuguesas. Nesta tabela destaca-se também a boa posição global ao nível dos downloads mas muito má no que respeita os uploads.

Experimente para optimizar

Com estas duas ferramentas pode optimizar o seu blog e tirar as teimas quanto à habitual explicação "ah e tal, é da ligação" :) Boas experiências.

image
Entre em http://draft.blogger.com e navegue até Editar páginas como se vê na imagem supra.
O que são páginas autónomas?
http://www.google.com/support/blogger/bin/answer.py?answer=165955
Com mais tempo, voltarei ao tema.

NOTA: a página About é um exemplo destas páginas autónomas. Note-se que o URL é diferente do habitual.

HTML 5

Posted by Mr.Editor 0 comments

html 5 
gallery

O HTML é a linguagem da web e o HTML 5 é a versão que se prepara para ser a próxima.

Veja no site http://html5gallery.com exemplos de sites que já usam HTML 5. Para ver estes sites precisará de um dos seguintes browsers: Chrome, Firefox 3.5, Opera ou Safari.

Um bom artigo de introdução está disponível aqui: Get Ready for HTML 5.

Neste post vou mostrar como adicionar os os botões de partilha no Twitter e no Facebook. É fácil. O aspecto final será algo como na imagem seguinte, em que os botões aparecerão do lado direito do título do post:

image

Siga então os passos seguintes:

  1. Antes de mais, faça uma cópia de segurança da sua template. Muito importante! Permitir-lhe-á desfazer algum erro caso se engane. Veja aqui como: Fazer cópia de segurança da template
  2. Depois terá de modificar a template. A melhor forma de o fazer será fazendo uma cópia do ficheiro descarregado e depois editando a cópia com o Bloco de Notas do Windows (Notepad) ou, ainda melhor, usando o excelente Notepad++ (freeware).
  3. Na template, procure este pedaço de texto:
    ]]></b:skin>
    e imediatamente por cima abra uma linha em branco e cole o seguinte texto:

    .retweet { /* estilo da div de partilha */
    float:right;
    padding: 5px 0px 0px 5px; 
    }

    Isto cria um estilo CSS para posicionar os botões de partilha.

  4. De seguida, procure o seguinte pedaço de texto
    <div class='post'>

    nota: se não encontrar o pedaço de texto anterior, procure algo parecido. O importante é que comece por <div e contenha class='post'
    e imediatamente a seguir abra uma linha em branco e cole o seguinte texto:

    <!—SHARE begin -->
    <div class='retweet'>
    <!-- FACEBOOK share –>
    <a expr:share_url='data:post.url' name='fb_share' rel='nofollow' type='button_count'/> 
    <script type="text/javascript" src="http://static.ak.fbcdn.net/connect.php/js/FB.Share"/
    <br /><br />

    <!-- TWEETER share --> 
    <script type='text/javascript'>
    tweetmeme_style = 'compact';
    tweetmeme_url = '<data:post.url/>';
    tweetmeme_source = TwitterUserName; 
    </script> 
    <script src='
    http://tweetmeme.com/i/scripts/button.js' type='text/javascript'/>   
    </div>
    <!-- SHARE end -->

  5. Altere o texto vermelho em cima para ser o seu utilizador twitter.
  6. Grave o ficheiro. Vá ao blogger e carregue a nova template. Para isso, vá a Esquema – Editar HTML, clique em "Choose File" (ou o correspondente em português), seleccione o ficheiro que gravou e clique em carregar.
    image
    A template será automaticamente carregada.
  7. Veja o resultado. Se houver algum erro, reponha a template anterior (veja aqui como: Fazer cópia de segurança da template) e analise em detalhe se fez as alterações indicadas.
    E é isto, está feito. Boas blogagens.

Quem o recomenda é o governo alemão, que incentiva os utilizadores da web a escolherem outro browser. Há quem defenda que esta recomendação deva ser tomada em conta não apenas por aqueles que ainda usam o Internet Explorer (IE) 6 como também por todos todos os que usem as versões 7, 8 ou outra que aí venha.
Operação "Aurora"
Vem este assunto a propósito do recente ataque a mais de 30 empresas americanas, incluindo a Google, a Adobe e a Juniper Networks. O ataque ocorreu na época natalícia, possivelmente para minimizar as possibilidades de detecção e recorreu a uma nova falha de segurança no IE, como descreve a McAfee, ainda não conhecida publicamente. Os intrusos ganharam acesso às organizações em causa lançando ataques a muito personalizados a uma ou a um restrito grupo de pessoas com acesso a informação sensível. Estas pessoas foram o ponto de acesso ao material que se pretendia roubar: propriedade intelectual.
"Aurora" é nome como está a ser conhecido este ataque e resulta da análise feita pela McAfee. Investigando o código binário do "malware", a McAfee descobriu que a palavra "Aurora" fazia parte do "filepath" (localização no disco) da máquina atacante. O "filepath" pode ser inserido pelos compiladores de código para ajudar à correcção de erros de software (debug) e para indicar onde o código fonte está localizado na máquina do programador. A MCafee acha que "Aurora" foi o nome interno que o(s) atacante(s) deu(deram) à operação.
Novo patamar
Até agora temos visto ataques para obter informação bancária. Com o presente ataque, é a propriedade intelectual o que está em causa, o que coloca a guerra virtual noutro patamar. Quando a actual tendência é tudo estar ligado, é altura das empresas de software pensarem seriamente mais nas questões de segurança do que nos "press release". Começar por não lançar no mercado software mal testado, numa estratégia comercial de antecipação, é um bom começo.
Leituras:

Adenda:
Segundo o i, a França está a fazer a mesma recomendação.

Como enviar pings automáticos para o Twingly e para o Wordpress.
Dica válida para quem publique em Wordpress e em Blogger

Aos leitores dos jornais Público e i não será estranho o serviço Twingly que lista os blogs que ligam para uma notícia. Funciona assim:

  • O dono do blog escreve um texto com uma referência a uma notícia;
  • Envia-se uma notificação (ping) ao Twingly;
  • O Twingly actualiza a sua lista de blogs que ligam para a notícia.

Fantástico, não é? Nim. Se o leitor publica na plataforma Wordpress, então o este serviço é automático. Se, por outro lado, publicar no Blogger, então terá que ir manualmente ao site do Twingly e fazer um ping manual. Uma seca! Para menorizar o problema, também pode guardar a página de ping nos favoritos (algo como http://www.twingly.com/ping?url=http://fliscorno.blogspot.com) e sempre poupa tempo.

Mas se já estiver a escrever os seus textos no Windows Live Writer (WLW) como eu, então tenho boas notícias: o ping pode ser automático! E mais, além do Twingly também pode mandar mandar pings para outros servidores, tal como o Ping-o-matic e ver nos blogs da plataforma Wordpress os respectivos pingback.

Para tal, basta no WLW ir ao menu Ferramentas | Opções e em "Enviar Ping aos Servidores" colocar o texto seguinte:

http://rpc.twingly.com
http://rpc.pingomatic.com

O resultado fica assim:

Windows Live Writer, Ping

Fácil, não é?

Sugestão: siga esta e outras dicas assinando o feed
http://feeds.feedburner.com/fliscorno_blog_tips

Followers