AkitaOnRails.com

[Off-Topic] Restaurantes e Tecnologia

Wed, 18 Nov 2009 12:51:07 PST

Existem desenvolvedores e desenvolvedores. Existem empresas e empresas. Apenas para efeitos ilustrativos deste post eu vou separar pelo menos dois tipos de empresa: onde tecnologia faz parte ou é o core business, onde o gasto relacionado a tecnologia é considerado de fato “investimento”; ou empresas onde tecnologia é apenas acessória, considerada meramente parte do “custo operacional”, onde apenas somente para suportar o negócio, que é muito do que chamamos de “backoffice”. Na falta de termos melhores, chamarei empresas onde tecnologia é core business de “empresas de tecnologia” e os outros de “enterpriseys” para facilitar.

Por que estou dizendo isso? Porque muitas decisões são tomadas fora desse contexto. Decisões que normalmente se encaixam bem em enterpriseys são tomadas em empresas de tecnologia e vice-versa. É um dos motivos de muitas discussões inúteis. Eu consigo entender porque um banco se sentiria incomodado de implementar hoje uma nova tecnologia, vamos chutar, trocar alguns de seus DB2 por um CouchDB por exemplo. Também consigo entender porque uma empresa médica ficaria relutante em trocar seus atuais programas embarcados de C, por exemplo, por .NET micro framework. Não quer dizer que nenhuma delas tenta, mas sim que não é o caso da maioria e nem que as tecnologias não funcionariam.

O mesmo não pode ser dito de “empresas de tecnologia”. Nesse contexto, tentar usar o que há de mais novo e mais avançado deveria ser o normal. Mais do que isso: criar as próprias tecnologias deveria ser o normal. Agora, a preocupação é que isso fique aleatório, desordenado e leve ao caos. Não se trata disso. É justamente por isso que empresas de tecnologia como Google, Microsoft, Novell, RedHat e diversos outros menores tem algo que se assemelha a um departamento de “Research & Development” (pesquisa e desenvolvimento), ou no mínimo a noção de “pesquisar e experimentar”. É por isso que eles se esforçam em contratar os profissionais do mercado que estão na ponta das novas tecnologias, coisa que não faz sentido por exemplo em um banco, ou uma seguradora, ou uma empresa de transportes.

Esse pensamento parece óbvio e realmente é, mas por alguma razão eu vejo pessoas decidindo e discutindo coisas fora desses contextos, coisa que é particularmente irritante. Tecnologias mais recentes de código aberto, por exemplo, fazem total sentido em empresas de tecnologias. Mais do que isso: ter funcionários contribuindo para projetos de código aberto faz mais sentido ainda.

Para facilitar a analogia, eu disse que em “empresas de tecnologia” o core business é tecnologia (duh). Agora pense num restaurante. Nesse caso trata-se de uma empresa onde o core business é cozinhar bons pratos culinários. Se nessa empresa eu decidir, fora do contexto, e pensar como se a comida fosse apenas acessória, poderia dizer: “porque não terceirizamos nossa cozinha e passamos a comprar hamburgers do McDonald’s? Vai diminuir nosso custo operacional, teremos entrega garantida nas quantidades que precisamos. Mais do que isso, o mercado todo já conhece e gosta.”

Pior ainda, se os cozinheiros desse restaurante tivessem a mentalidade: “ah, não quero testar esse novo ingrediente porque vai dar mais trabalho. Prefiro pegar o tempero já pronto no mercado.” É o que eu chamo de “cozinheiros de ovos mexidos”. Isso porque qualquer um consegue fazer ovos mexidos.

Em enterpriseys, normalmente a maior parte do trabalho é literalmente “desenvolvimento de formulários e relatórios”, o que justifica a existência de Fábricas de Software e a contratação de “codificadores”, o típico funcionário de restaurante que apenas esquenta a comida congelada de terceiros no micro-ondas.

E eu também sempre diferencio um “codificador” de um “desenvolvedor”. Um desenvolvedor precisa ter a cabeça de um “chéf”, um verdadeiro cozinheiro, tentando coisas novas, testando novos ingredientes, arriscando novos pratos. É o que diferencia um chéf premiado de um funcionário que apenas esquenta uma grelha. Sem querer denegrir a profissão, estou apenas tentando ilustrar um conceito. E o problema é quando um esquentador de micro-ondas acha que é cozinheiro e o que ele está fazendo é gastronomia. Não é.

Vale uma ressalva: não estou dizendo que não existem “cozinheiros” em consultorias ou enterpriseys. O que estou apontando é como a empresa encara esse tipo de serviço ou gasto. Como ex-consultor estou mais do que ciente que existem grandes mentes tentando influenciar e mudando o mindset de muitas indústrias. Exemplo claro disso é a Thoughtworks, por exemplo.

Portanto, antes de mais nada, veja em qual contexto você está. Se estiver num restaurante de verdade, espera-se que você seja um cozinheiro. Não ache que agir como um esquentador de micro-ondas está correto, a menos que você queira levar o restaurante à falência.

Outro exemplo do nosso mundo: acho que todos que lêem o meu blog conhecem o Github, um dos repositórios de código-aberto mais inovadores da atualidade. Tentem colocar isso nas suas cabeças: foi o trabalho de literalmente 4 programadores, alguns deles que mal acabaram de sair da faculdade. Eles poderiam usar tudo que é considerado “aceitável” pelo “mercado”. Leiam este blog post deles: Como fizemos o Github ficar rápido. Se você aspira ser um “chéf” nenhuma das tecnologias citadas deveria ser novidade: ldirectord, nginx, unicorn, rails, drdb, proxymachine, haproxy, redis, ernie, memcached. Querem mais? Ao mesmo tempo, só recentemente, eles lançaram duas novas tecnologias: Resque e BERT-RPC. Vou repetir: não muito mais que 4 pessoas.

Querem mais? Lembram do Phusion Passenger e do Ruby Enterprise Edition? São dois garotos que nem saíram da universidade. Eles são “chéfs”.

Em uma empresa de tecnologia, essa é a meta. Em enterpriseys não. Onde você está?

Chatting with Adam Jacob

Wed, 18 Nov 2009 07:46:21 PST

Configuration Management is a tricky subject. For non-starters, when you’re a developer and you have few boxes to take care of, you can usually get away with just managing them manually. People are probably just used to pop in a CD, double-click the “install” program and click “next”, “next” until the end, then you manually log in to backup (when you remember it), and sometimes you do apply some security updates when you remember about them.

But then you have more than a dozen machines, things start to get uglier, you end up making more mistakes, forgetting important steps, and all of a sudden managing machines become a nightmare. You end up being woken up in the middle of the night because you forgot to install some crucial component, and so on and so forth.

The same way you need testing, continuous integration tools when you’re a developer, you also need automated, reliable and flexible tools for the system administrator role. That’s where tools such as Chef kick in to help.

From Opscode Inc., we have Adam Jacob (CTO) and Jesse Robbins (CEO) to talk about the new contender in the automated system administration field, Chef, already in use by many companies which are striving with the cutting edge to maintain their datacenters.

AkitaOnRails: To kick start this interview, it would be great to have more background info about you guys. So, how did you end up in the configuration management space?

Adam: I’ve been a systems administrator for 13 years, and for a majority of that time I was working for companies who did a lot of mergers and acquisition work. Every couple of months we would acquire a new company, and it was my job to help figure out how to absorb those companies into the whole. I got really good at looking at an application I had nothing to do with creating, and figuring out what needed to be done to make it scale (or at least make it run.)

One thing we couldn’t do was tell the people who had built the applications that they needed to be radically altered (in many cases, they weren’t even around anymore.) What that meant in practice was we needed to have a very flexible, modular underlying architecture – everything we did had to be in service of the application, not the other way around. By necessity that meant becoming a tools developer – if we didn’t have the tools we needed, we would never be able to do the job in front of us.

Eventually I co-founded a consulting firm called HJK Solutions. We built fully automated infrastructure for startups – everything from OS installation to application deployment, all fully automated (including Identity Management, Monitoring and Trending, etc.) Over the course of the next two years we built infrastructure for 12 different startups, whose products ranged from electrical car fleet management to online dating.

So I come to configuration management through the trenches – as a line-level systems administrator trying to make my life easier, as a consultant helping others to reap the benefits, and now as a tool builder trying to move the state of the art forward.

Jesse: Jesse Robbins is CEO of Opscode (makers of Chef) and a recognized expert in Infrastructure, Web Operations, and Emergency Management. He serves as co-chair of the Velocity Web Performance & Operations Conference and contributes to the O’Reilly Radar. Prior to co-founding Opscode, he worked at Amazon.com with a title of “Master of Disaster” where he was responsible for Website Availability for every property bearing the Amazon brand. Jesse is a volunteer Firefighter/EMT and Emergency Manager, and led a task force deployed in Operation Hurricane Katrina. His experiences in the fire service profoundly influence his efforts in technology, and he strives to distill his knowledge from these two worlds and apply it in service of both.

AkitaOnRails: What’s the story behind Opscode, what’s its mission, and what’s the story for Chef’s creation?

Opscode: The story behind Opscode really starts when we met Jesse. He had written an article for O’Reilly Radar about Operations being the new secret sauce for startups. He and I met for coffee, became friends, and stayed in touch. Jesse understands operations culture at a visceral level, and he’s very well connected to a huge community of like-minded people that I didn’t even know existed.

As our consulting company grew, we reached a crossroads – we clearly had a nice business going, and it wasn’t difficult for us to find more work. What was difficult was finding people who had the skills to actually deploy a new infrastructure, and to adapt the stack we had developed for a new application. We couldn’t avoid the fact that there was a couple of weeks of very high-touch work that was required to get the entire infrastructure up and running for a new client.

We tried to recruit Jesse during this period, since he was one of those rare people who could do that initial high-touch engagement. He turned us down – primarily because he saw what we did: we could build a consulting company that was huge, but it would still be down to us in the trenches every day. Unless we could get over that hump, there were probably less stressful ways to make a living. :)

So we started looking at what was stopping us from being able to get that initial part of the engagement done as quickly as possible. What was stopping us from literally having a customer fill out a questionnaire, and letting that data drive 95% of the decisions about the infrastructure?

It turned out the answer was, in a word, “everything”. The entire stack of open source tools we were using had been built in a different era, and they saw the world through a very different lens. We needed everything to have an API, we needed everything to be more open with it’s data, and we needed everything to be flexible enough to handle the next evolution of application architectures (whatever that may be.)

Once we had that revelation, the next step was figuring out what a ‘new stack’ would really look like. If we could start from scratch, what would we take with us, and what would we leave behind? Amazon had done such a great job showing us what an API over the bootstrapping process could look like, and the kind of benefits that could be had from the approach. So assuming something like that existed for bootstrapping, what about the next layer of the stack (configuration)?

We started experimenting with Chef during this period of questioning. We started working on Chef with the goal of putting ourselves out of business – making the barrier to entry to having a fully automated infrastructure so low that any developer or systems administrator could just do it. We built a prototype, showed it to Jesse, and he agreed to come on board.

Opscode was born then, and our mission came out of those experiments: we are bringing Infrastructure Automation to the Masses. We want to tear down the barriers to entry that stop people from having really great, repeatable, automated infrastructure. Our role is to bring developers and systems administrators the best tools possible, so that they can build the systems they have always wanted.

We raised 2.5 million from DFJ in January of 2009 on that vision, and have been at it ever since.

AkitaOnRails: I’d like to say that only amateur sysadmins do everything manually, but I think most small to medium corporations at least still do everything manually or with random scripts spread all over the place. The notion of “configuration management” is still new to a lot of people. Could you briefly explain what it is, and why it is important?

Opscode: To me, “Configuration Management”, at it’s core, is all the stuff you have to do to take a system from “running an operating system” to “doing it’s job”. When a systems administrator configures a system by hand, and posts her notes on a Wiki, she’s practicing the most primitive form of Configuration Management.

Now, having those notes is better than nothing – when she needs to do that task again, she can at least go back and read them to remember what she did last time. She still has to do it over again, though – and the repetition gets tiresome. So she starts writing scripts that encapsulate that knowledge in code, so that now she only has to run a series of smaller commands.

Time passes, though, and entropy sets in. The systems begin to drift from where they were when the systems administrator wrote the scripts. Next thing you know, the scripts don’t run anymore, or if they did, the configuration they build is wrong. Our intrepid admin then starts editing the scripts, or making new ones, to deal with the system when it’s in this new state. This is the stage we call “tool sprawl” – you have a tool for each different phase of a systems observable life-cycle.

Modern configuration management tools solve this problem by providing a framework for describing the final state a system should be in, rather than the discrete steps we should take to get there at any given time. Rather than writing a script that lists the commands to install Apache, write the configuration file, and start the service, you would describe that “apache should be installed”, the configuration file “should look like this”, and the service “should be running”.

When the configuration management system runs it looks at each of these descriptions individually, and makes sure that they are in the proper state. We no longer care what the initial state of the system is – the configuration management system will only take action at each step in the process if the system is not in the state you described. If you run it again, and nothing has changed, the system takes no action. (Configuration management geeks call this property idempotence)

This means that you can describe your systems once in code, and as they change over time, simply update that code to reflect what you want the state of those systems to be. The impact of this model on the daily life a systems administrator cannot be overstated – it makes everything easier.

It also has huge impacts outside the systems administrators world. You now have a living document that describes how all your servers are configured – you can share it, you can put it in revision control, you can print it out for an auditor. Business processes that previously required manual intervention frequently can be boiled down to discrete changes. The more you work in this way, the more the impacts spread throughout the organization.

AkitaOnRails: Even though the Ruby community probably compares Chef to Puppet, I think one of the most widely used system is CFEngine2. How does Chef compare with CFEngine2?

Opscode: Cfengine 2 is where almost everyone in the configuration management world cut their teeth. Mark Burgess is responsible for the academic papers that outlined the idea that each part of the system should be idempotent, and his work in studying how real-world systems can be managed at scale has done more to impact the evolution of configuration management than any other individual.

In addition to the idea of idempotent resources, Burgess introduced the larger concept of “convergence”. The basic idea here is that if you have the description of how every finite resource should be configured, given enough time, those resources will bring the system into a compliant state. The order in which the resources run fundamentally does not matter – eventually, they will all wind up in the right place.

While this model works at a fundamental level, it has some pretty dramatic inefficiencies. Cfengine applies resources based on their type – all the files are managed at once, then all the services, then all the packages. You can control the order they are run with the ‘actionsequence’, but each system gets only one order. So if you need to have a file copied, a package installed, and a service restarted, it’s easy enough to model. When you start getting into more complex configurations, however, it becomes more and more difficult to get an actionsequence assembled that allows you to configure your entire system in a single run.

This is not a bug in Cfengine – it’s by design. Convergence is the answer – it’s okay that it has to run more than once, it will get there eventually. If you are thinking too much about the order things should happen in, you’re probably not thinking about idempotent descriptions.

In my experience, though, this was frustrating at scale. It meant that the amount of time it took to configure a system increased as the configuration became more complicated, and your ability to model complicated interactions in the system became increasingly opaque.

For the era in which it was written, this problem mattered a lot less. If it takes you 6 to 8 weeks to get a server even ordered, then another week to get it racked, stacked, and the OS installed, the fact that Cfengine needs to run 3 times to configure it doesn’t matter very much. (You have lots of bigger problems!) In a world where many of us can go from bare-metal to running operating system in 5 minutes, either via our own install systems or an API call to AWS, it starts to matter a whole lot.

Chef takes a different approach. We start with the idea of an idempotent “resource” – a package, a service, etc. We add the idea of “actions” – these are all the different states you might want to request a resource to be in. Then you put these resources into “recipes”, which are evaluated in the order they are written. You can then have recipes rely on other recipes having completed before they are run, giving you the ability to say “make sure Apache is installed before you configure my Web Application”.

The goal is that, with Chef, you can always bring the system into the proper state with a single Chef run. It sees convergence as a response to a bug – a system that is 1/2 configured is, in fact, broken. If the cause of the bug is environmental – a network service is not available, for example – then running Chef again will likely fix things. If the issue is that you haven’t specified the order that you want resources to be configured in, though, then it’s a bug in your recipes. If you can’t write a recipe to configure your system in a single Chef run, it’s a bug in Chef.

This also has side-effects for reasoning about the system at scale. Given the same configuration and attributes, Chef will always behave the same way, on every system. As you add more and more things to the system, it’s still easy to reason about when, and how, they will be configured.

Interestingly enough, Cfengine 3 implements a system that is very similar to Chef. Rather than a single global actionsequence, it uses a ‘bundlesequence’, where bundles are roughly analogous to Chef’s concept of a recipe.

Another major difference is that Chef allows you to ‘look up’ at your entire infrastructure when configuring a system. This ability comes in handy when you want to do things like configure a monitoring system, or a load balancer. You can ask Chef questions like “what are all the servers running my application in production”, and use the response to configure your system. (You can see an example of this on our blog)

From a systems architecture point of view, Chef and Cfengine are actually fairly similar. They both push the majority of the hard work of configuring a system out to the systems themselves. This is highly advantageous at scale – the Chef and Cfengine servers are really glorified file transfer systems.

We differ pretty deeply on our approach to what a language for configuration management should look like, but I’ll talk more about that in a later question.

Cfengine is at work in some of the largest data centers in the industry, and it fundamentally altered the landscape of systems management. While it’s not the tool I want anymore, you can’t understate the impact it’s had on the design of every configuration management tool that came after it – including Chef.

AkitaOnRails: Chef has a lot of components to it. Could you briefly describe all the main components that work together? The client side, the server side, cookbooks?

Opscode: Sure! The most important part of Chef is the cookbooks – they are where you actually describe your configuration. They collect recipes, and all the assets needed for the recipe to run (files, templates, etc.). Cookbooks are very often share-able, and lots of cookbooks already exist.

Chef can run your cookbooks in two modes – a client/server mode (chef-client), or a stand-alone mode (chef-solo). When you run chef-solo, you pass a URL to a tarball full of the cookbooks you want to have run. There is no more infrastructure than that – put your tarballs someplace you can download them, and go nuts.

In client/server mode, each Chef client is configured to talk to a Chef Server. The Server stores information about each client (a whole lot of it – things like IP addresses, loaded kernel modules, and more), and distributes the cookbooks they need to configure themselves. It also provides a REST API and an interactive Web UI, so you can easily alter the configuration of your systems centrally. Finally, all the data the server collects is indexed and searchable – you can then use this in your recipes to configure services that require complex, dynamic configuration. (Some examples would be dynamically discovering a master MySQL server, or finding all the memcached servers in a cluster)

AkitaOnRails: What would you say about Chef’s maturity? CFEngine has more than a decade of usage, which is difficult to beat. Would you say that it’s “mature enough”? Meaning, it’s already in production in companies of many sizes, its APIs don’t change too much and my cookbooks will probably work if I upgrade to newer version of Chef?

Opscode: Chef is a little over a year old – it was first released to the public on January 15th, 2009. Since then, 42 different developers have committed to the project, around 5 of whom work for Opscode. It’s been in production use in the Engine Yard Cloud from the day it was released. Since then, it’s seen adoption by companies and universities of all different sizes, from small startups to huge enterprises with very heavy compliance requirements.

So it’s definitely “mature enough” for real world use – lots of people are using it, and relying on it, every day. Balancing that knowledge with the reality that the project is fast moving and evolving is important, and we try and do it in a number of ways:

The recipe syntax is considered basically “complete”. If we do make changes, they are backwards compatible to previous Chef releases. Short of something truly amazing coming along that radically alters the shape of the universe, this will remain true.
We test a lot. Chef has over 2000 unit tests, and functional tests that cover the entirety of the REST API, and much of the individual resources (we’re aiming for 100% feature test coverage.) There are more lines of code testing chef than there are lines of code in Chef proper.
If we do break backwards compatibility, we try and make it happen only when we bump the minor revision. If you have an 0.7.x version of Chef installed, it should always work with other versions of Chef in the same release cycle.

Most of the work in Chef currently is around adding more functionality, not in changing the way existing functionality works. It’s safe to use Chef today – in the future, you’ll just keep getting more good sauce to add to the mix, rather than having to deeply re-factor the way you do things.

Finally, the Chef Community is truly epically great – we have lots of people who are spending significant amounts of their time with Chef. Even if they aren’t contributing code, they are answering questions, they are writing documentation, they are hanging out on IRC and offering you cupcakes. It’s a group of people that are focused on solving real world problems, and helping each other to do the same. It’s by far what I’m proudest of, and I think it has a significant impact on whether Chef is ready for prime time. The bench is really, really deep.

AkitaOnRails: Chef uses Ruby directly, which some would say it’s both a blessing and a curse. It’s probably perfect for Rubists, but I feel that most sysadmins are used to Bash, Python and are not very flexible on change. Why did you choose to use Ruby instead of a simpler language?

Opscode: The answer to the question of why we use Ruby directly for the configuration language comes in two parts: why we extended a 3GL rather than build a declarative DSL or a complete modeling language, and why we chose Ruby as that 3GL.

First, why we extended a 3GL. Tools like Cfengine and Puppet build a declarative DSL for configuration management – a custom language, which provides a model within which systems administrators or software developers can work to automate their system. Other tools like Elastra’s EDML and ECML, OpsWare’s DCML, or Bcfg2 give you an XML schema to describe how the system should behave.

The issue with these approaches is that, by definition, they must build an abstraction for every task the end-user may want to perform: an impossible feat. The level of complexity inherent in automation, coupled with the inability to break out to 3GL language constructs when necessary, result in a system that can only target a subset of the total complexity, rather than enable users to find innovative solutions to their specific problems. By leveraging Ruby, adding support for other use cases is a matter of adding new sets of base classes while maintaining consistency and approachability in their interface design, because the full scope of the language is available.

Our goal with Chef was to keep the simplicity that comes from having the focus be on idempotent resource declaration, while giving you the flexibility of a full 3GL. In practical terms, anything you can do with Ruby you can do with Chef – and since Ruby is a 3GL, that amounts to essentially anything.

Larry Wall, the creator of Perl, has a quote that I love:

“For most people the perceived usefulness of a computer language is inversely proportional to the number of theoretical axes the language intends to grind.”

Since we wanted Chef to have the maximum amount of usefulness, we have actively tried to remove as many theoretical axes as possible – a belief that we can imagine the total breadth of the problem space being one of them. There is more than one way to do it with Chef, and the only valid criteria for rating the success of your automation project is whether it solves your problems in a reliable way.

In practice, you need to know very little Ruby to use Chef. Here is an example of installing the program “screen”:

123	package "screen" do action :installend

The same thing in Puppet:

123	package { "screen": ensure => present }

And in Cfengine 2:

12	packages: screen action=install

While all of these systems require learning the syntax, at a base level, there isn’t much difference between them in terms of raw learning required. The difference is that when you hit a limitation in Chef, you have the ability to innovate easily, and when you hit those same limitations in other tools, you do not.

We chose Ruby because of it’s fairly unique ability to create new syntax easily. Tools like Rspec are fine examples of ways you can manipulate Ruby for fun and profit that are very difficult to duplicate in other tools. We wanted to make sure that, even though you were “in” a 3GL, you didn’t have to go through any extra hoops to make the simple things work. Ruby was the language that I was comfortable enough in, that I knew had the ability, to make that a reality.

That said, one of our goals is to extend the ability to write Chef recipes into other 3GL’s. We have an example of doing this already with Perl – and we made no changes to the Chef source to accomplish it. You can see the demo here on CPAN. It works by using Chef’s JSON API to ship the compiled resources over to the Ruby library for execution, and over time we’ll be extending those interfaces. You’ll be able to have recipes written in Python interoperating with recipes written in Ruby and Perl.

AkitaOnRails: Does Chef have (or for that matter, need) something like Augeas, which Puppet is trying to support?

Opscode: Augeas is neat. Chef doesn’t have Augeas support today, and the reason is that nobody has needed it badly enough to write the integration. One reason is that, with Chef, it is quite easy to dynamically add to a resource (like, say, a template) or search for particular systems that match a criteria. This means that the use-case for Augeas (which edits files in place) is less necessary – you can often get the data you need to render a template, rather than needing to build it up over time with incremental edits.

We think this is a better practice in general, as it ensures that all the systems you are managing can always be restored to a working state from nothing but the cookbook repository. If you use Augeas to allow idempotent changes of individual lines of a configuration file, it encourages the behavior of individual administrators editing files in place, which is a configuration management anti-pattern.

AkitaOnRails: Sysadmins used to CFEngine complain about Ruby’s dependencies and overall weight. Because for Chef to run you need Ruby installed. Not all distros have Ruby in the same version (although most already migrated to 1.8.7). Then you have the problem of weight. I am not familiar with Chef, but Puppet can grow to hundreds of megabytes. What they don’t want is to have clusters of Chef machines (which, by themselves, also need maintenance, adding to the overall complexity). How do you deal with datacenters with thousands of servers? I know it’s difficult to measure precisely, but what would be a reasonable ratio between Chef servers x managed servers?

Opscode: When you are evaluating the scalability of configuration management systems, you want to look at two different axis. The horizontal one, which is the number of systems that can be managed by a single configuration management server at a particular rate of change, and the vertical, which is how much of your infrastructure can be automated by the tool.

On the vertical axis, I think Chef is the clear winner, for reasons I think are pretty well summed up by my answer to question 7. I would put Puppet second, and Cfengine last.

On the horizontal axis, Cfengine is the clear winner. It’s written in C, and it has the thinnest possible server component – it does nothing but authenticate clients and serve files, essentially. I know first hand of data-centers that are running huge numbers of servers off a single cfengine server.

One important metric to keep in mind when discussing the horizontal scalability of a configuration management solution is that the most important metric is the rate of change. All the tools we’ve been talking about are ‘pull’ based – the clients check in at an ‘interval’ with the server, and apply a ‘splay’ to ensure that not all the systems check in at once. A common out of the box configuration is an interval of 30 minutes, with a splay of 15 minutes. (This means a server checks in every 30-45 minutes, depending.) If you are comfortable increasing that interval, you will get more scalability out of fewer resources (by lowering the amount of concurrency.)

So when anyone says “I have 10 thousand servers on a single configuration management server”, ask them “at what interval?”.

Chef scales like a web application. The server itself is quite thin, and is responsible for authenticating clients, transferring files, storing node state, and providing a search interface. It scales horizontally by adding new Chef Servers as necessary. The API is RESTful, and there is no session state between the clients and the server. (At least not in Chef 0.8+) When you encounter scalability problems with Chef, the tools you apply are the same ones you apply to any well designed web application.

You asked specifically about memory utilization – Chef does quite well in this regard. Individual server processes usually are between 14-50MB resident. The client itself, running in daemon mode, is usually around 28MB resident.

In our testing, the current bottleneck in a Chef server is CPU. Chef is smart about how it handles file transfers – we only transfer files that have changed on the server. To support this we calculate a checksum for each file requested, and we currently don’t cache the results. We’re planning on fixing this for the next major release of Chef (0.8.0) which should shift the bottleneck over to RAM.

With Chef 0.7, you should be able to support thousands of clients at a half-hour interval and fifteen minute splay on reasonable commodity hardware. The changes in Chef 0.8 should bring that number up dramatically – I’ll get back to you with some benchmarks once the patches are in. :)

AkitaOnRails: Probably related to the previous question, seems like specially after Sarbanes Oxley there’s been an increasing interest in stuff such as ITIL, CoBit. Have you ever seen successful implementations of those in the Web-style infrastructure? I mean, I can see them succeeding in Banks, Aerospace and Defense, etc but I fail to see them working as advertised in a very dynamic environment such as Web services hosting. What are your experiences regarding this issue?

Opscode: Well, I think you can think of ITIL in the same way you think about the classic ‘Waterfall’ model of software development. For some kinds of projects and companies, it is essential – it’s hard to imagine working a different way. Most often these are companies with huge manufacturing or quality control concerns – medical health, aerospace, banking and finance, etc.

The same thing applies to ITIL – the larger the concern, and the more stringent the requirements, and the longer the lead time, the more the processes they describe start to make sense. Like all large process, though, they tend to de-emphasize the human element – people have roles to play, and forms to file. :)

In the Web Ops culture, things are different. I’ve never seen a successful marriage of ITIL and Web Ops, and the reason is that the domains are so very different. If there is a bug on the website, it’s better to ship the fix now than wait for a release management process to ensure that the site won’t have any more issues based on your fix, for example. It’s also a bad cultural fit – in the best Web Ops teams, the focus is heavy on communication, agility, and respect, rather than process, formalism, and tooling. The shift you start too see in the really great Web Ops companies is that their operations personel become enablers of the organization, rather than end-line blockers of change (to keep stability high.)

In general, I think the 4 steps outlined in visible ops for emergency management are not bad ones, but the devil is always in the details. The guy you should really ask about this is Jesse – he’s largely responsible for Amazon’s operational culture, and knows what it means to start hacking on that sort of thing from within huge organizations.

AkitaOnRails: Awesome, I think this is a wrap. Thank you very much for this interview!

Chatting with Luke Kanies

Wed, 18 Nov 2009 07:45:32 PST

This time I’ve interviewed Luke Kanies, from Reductive Labs, former contributor to the famous CFEngine tool and creator of Puppet, one of the most acclaimed configuration management tool for 21st century datacenters.

AkitaOnRails: To kick start this interview, it would be great to have more background info about you. So, how did you end up in the configuration management field? I understand that you have a long history with CFEngine development, right?

Luke: I was a Unix admin going back to 1997, always writing scripts and tools to save myself time, and around 2001 I realized that I shouldn’t have to write everything myself – that someone somewhere should be able to save me time. After a lot of research and experimentation, I settled on Cfengine, and had enough success with it that I started consulting, publishing, and contributing to the project.

AkitaOnRails: What’s the story behind Reductive Labs, what’s its mission, and what’s the story for Puppet’s creation?

Luke: After a couple of years with Cfengine, I had a lot more insight but was frustrated because it still seemed to be too hard – no one was sharing Cfengine code, and there were some problems it made you work really hard to solve. The biggest issue, though, was that its development was very closed – it was difficult to contribute much more than just bug fixes.

I got frustrated enough that I stopped consulting and looked for other options. I worked briefly at BladeLogic, a commercial software company in this space, but in the end I decided that the insight I had and the lack of a great solution were a good enough start for a business that I decided to morph my consulting company into a software company and write a new tool.

Luke: It’s surprisingly difficult to describe it succintly, but for me, there are two key rules: You shouldn’t need to connect directly to a given machine to change its configuration, and you should be able to redeploy any machine on your network very quickly.

These two rules combine to require comprehensive automation and/or centralization for everything that goes into making a machine work. Annoyingly, they also immediately introduce dependency cycles, because your automation server needs to be able to build itself, which is always a bit of a challenge.

AkitaOnRails: I think one of the most widely used system is CFEngine2. How does Puppet compare with it? Meaning, what do I have as value added when switching to Puppet, and what are the known caveats?

Luke: There are multiple important functional differences. The biggest is Puppet’s Resource Abstraction Layer, which allows Puppet users to avoid a lot of the detail they don’t really care about, like how rpm, adduser, or init scripts work – they talk about users, groups, and packages, and Puppet figures out the details.

We also have explicit dependency support, which makes a huge difference – it’s easy to order related resources and restart services when their configuration files change, for instance.

The language is also a bit more powerful. Like Cfengine, we have a simple custom language, but Puppet’s language provides better support for heterogeneity, along with a composite resource construct that allows you to easily build in-language resource types like Apache virtual hosts that model more complex resources consisting of multiple simple resources.

AkitaOnRails: Puppet has a lot of components. Could you briefly describe some of the main ones that work together? The client side, the server side, recipes?

Luke: Most people use Puppet in client/server mode, where the central server is the only machine that has access to all of the code, and it runs a process capable of compiling that code into host-specific configurations. Then each machine runs a client (including the server), which then retrieves and applies that host-specific configuration. This has nice security implications because you’ve not shipped your code to every machine on your network.

If this model doesn’t work for you, though, it’s also easy to run Puppet stand-alone, where each machine has all of the code and compiles it separately. Multiple Puppet users do this for various reasons. This stand-alone ‘puppet’ executable is a standard interpreter – it can be used to run 1 line scripts or thousands of lines in a complete configuration.

Beyond this, we’ve got a few other interesting executables, such as to access our certificate authority functionality, and an interesting executable called ‘ralsh’ that provides a simple way to directly manage resources from the Unix shell, without having to write a separate script.

AkitaOnRails: What would you say about Puppet’s maturity? CFEngine has more than a decade of usage, which is difficult to beat. Would you say that it’s “mature enough”? Meaning, it’s already in production in companies of many sizes, its APIs don’t change too much and my recipes will probably work if I upgrade to a newer version of Puppet? I think the 0.x version makes some people nervous :-)

Luke: Really we should have called a version from 2007 1.0, but it’s hard to know how stable a release is going to be until it’s been out for a while. :)

It’s obviously tough to match Cfengine’s long life, although they’re somewhat forcibly migrating to Cfengine 3, which is a complete rewrite, so that maturity isn’t worth quite as much right now.

However, Puppet’s been in production usage around the world since 2006, and it’s currently used by more large companies than I could reasonably name – Twitter, Digg, Google, Sun, Red Hat, and lots more – and our community and customer base consider it to be mature. For the line came some time early last year, when I found that the vast majority of issues people had were user issues on their part, rather than some flaw or shortcoming in Puppet.

In general the APIs are quite stable, and we’ve done quite well, I think, at maintaining backward compatibility when the APIs have had to change. The point about API stability in a 1.0 release isn’t so much to differentiate it from previous efforts as to make a promise for the future. This especially matters for companies like Canonical, who want a release that they can support on Ubuntu for five years.

AkitaOnRails: Puppet has its own language and you can use Ruby for the advanced cases. It’s probably perfect for Rubists, but I feel that most sysadmins are used to Bash, Python and are not very flexible on change. Why did you choose to use Ruby instead of a more widespread language? What do sysadmins need to realize to shift paradigms?

Luke: Part of it is that most people don’t really need to know any ruby to be effective with Puppet. Sure, you can get some more power if you do, but if you’re not a language person, you’re perfectively functional with just Puppet.

Another nice thing is that we have a pretty smooth scale in terms of Ruby knowledge – you can start out writing ERB templates or five line extensions to Facter, which is our client-side querying system, and grow smoothly through to writing custom resource types.

In the end, I chose Ruby because I was most productive in it. I likely should have chosen Python, given its speed benefit and popularity at Red Hat and other places, but I found I just couldn’t write code in it. I started thinking in Ruby after only a few hours of usage, so it was impossible for me to turn away from it.

AkitaOnRails: Sysadmins used to CFEngine complain about Ruby’s dependencies and overall weight. Because for Puppet to run you need Ruby installed. Not all distros have Ruby in the same version (although most already migrated to 1.8.7). Then you have the problem of weight. Puppet can grow to hundreds of megabytes. What they don’t want is to have clusters of Puppet machines (which, by themselves, also need maintenance, adding to the overall complexity). How do you deal with datacenters with thousands of servers? I know it’s difficult to measure precisely, but what would be a reasonable ratio between Puppet servers x managed servers?

Luke: It’s as impossible to tell you how many clients a Puppet server can handle as it is to tell you how many clients a Rails server can handle – it all depends on the complexity of the tasks. Google scaled to 4500 client machines on a single server, but most people tend to add another server at around 500-1000 clients.

It’s true that it’s hard to keep memory usage down in a Ruby process, but we’ve made great strides in our recent releases by doing things like deduplicating strings in memory and being more efficient in our code paths. Really, though, we’ve spent a lot more time on features and bug fixing and less time on optimizing – until recently, we’ve been a small development team, and we just didn’t have the bandwidth for it.

Now that my company, Reductive Labs, has some investment, we’ve been able to add three full time developers, which is going to really help in this area.

As to dependencies, this is one area we break strongly from the Ruby community – we don’t require a single gem, other than our own Facter tool (and it’s usually not shipped as a gem). Rubyists tend not to worry too much about package dependencies – they just put it in vendor, as I’m fond of saying – but that doesn’t work when you have to deploy thousands of copies. So yes, you might have to install Ruby, but there won’t be any other dependencies you have to deal with, which greatly simplifies it.

It’s generally as tough to know how you’ll need to size your puppetmaster as it would be to size a web server – it depends on how complicated the workload is. In general, somewhere between 500 and 5000 clients, you’ll need to have a second server, but most people probably find it closer to 500. Really, though, if you’ve got 3000 clients hitting a service, you probably want to make it horizontally scalable for stability in additional to performance.

AkitaOnRails: Security is a big concern nowadays, Puppet was worried from the beginning on the handshake procedure between clients and server, can you describe it a little bit? Also, is there any built-in recipes for hardening machines, for example? Or at least any desires to add such tools in the future?

Luke: Puppet uses standard SSL certificates for authentication and encryption, including a certificate signing phase. By default, the client generates a key and a certificate request (CSR) and then uploads the CSR to its server. This upload, along with the later certificate download, are the only unauthenticated connections that are allowed by default.

From there, a human normally has to trigger the client’s certificate to be signed, but many organizations, including Google, automatically sign client certificates because they trust their internal network.

As to automatic hardening, there aren’t any recipes that I’m aware of right now, but it’s something that I’m definitely interested in. Years ago I was a big fan of TITAN, which is a hardening package for various *NIX platforms, and it was part of the inspiration to write Puppet – I’ve always wanted a portable, executable security policy.

AkitaOnRails: The puppetmaster uses Webrick by default, but the documentation also describes using Mongrel or Passenger. Are there any real gains in using those? Is it more for convenience or do we have performance/robustness improvements?

Luke: Holy cow Webrick is slow. It’s really fantastic for proof of concepts – get up and running in minutes. Once you get beyond that proof of concept, though, you really need to switch to Mongrel or Passenger. If you get more than one concurrent connection in webrick, your clients start to suffer, but you can scale to far more with the other solutions out there.

AkitaOnRails: Are there any clients case you are allowed to talk about? Meaning, more details on the kind of infrastructure, difficulties, caveats, best practices?

Luke: The possibilities here are pretty open ended. Google uses Puppet to maintain their corporate IT, which means they’re running it on thousands of laptops and desktops which is pretty different. MessageOne, a division of Dell, is really interesting in that their developers have to ship Puppet code to manage the applications that they ship, so if an app isn’t trimming its logs or backing itself up, it’s a bug that the app developer has to fix rather than the sysadmin. This really helps to bridge the divide between dev and ops, which has worked out really well for them.

Otherwise, there are lots of stores and best practices, but I’m afraid that would be a whole second article. :)

AkitaOnRails: I’ve seen Andrew Shaffer talk about Agile Infrastructure for a couple of years now, but I still think most IT organizations are unaware of this concept. Can you elaborate on what does it mean to be Agile outside of the development field?

Luke: I think Agile Infrastructure has even less adoption than Agile Development. The vast majority of IT shops haven’t changed practices significantly in years and are largely unprepared for the growth in server count that they’re experiencing. They mostly try to scale by adding more people, which we call the meatcloud, rather than scaling their tools and practice.

Luke: In general, I think these kinds of high-level policies are great for filings but aren’t so great for actually solving problems. The bigger a company is and the more public they are, the more likely they are to care about ITIL et al, but it doesn’t really help them solve problems outside of PR in my experience. You can be ITIL compliant and dysfunctional, or completely out of compliance but in fantastic shape. Considering that the best standards are derived from implementation and best practice, which few of these are, I don’t have a lot of hope for these being adopted by the best shops out there.

My personal experience is that very few companies ask or care about these standards, and the ones that do usually do so in a kind of checkbox way, in that they want to make sure they can check off things like CMDB but they aren’t really that concerned with the specifics.

AkitaOnRails: I think this is it! Thank you very much for this conversation!

[Tradução] Três Contextos Implícitos em Ruby

Mon, 16 Nov 2009 11:28:28 PST

[Tradução] Três Contextos Implícitos em Ruby

A desenvolvedora japonês @yugui escreveu um grande complemento ao artigo anterior sobre metaprogramação do Yehuda, que traduzo logo abaixo:

Yehuda Katz escreveu um artigo sobre self e metaclass. Nesse artigo ele disse que Person.instance_eval associa a metaclass de Person para self para uma classe Person, mas isso é obviamente errado.

12	class Person; end Person.instance_eval{ p self } #=> Person

Como mencionei em um artigo antigo, embora eu deva me desculpar por estar escrito em japonês, Ruby sempre tem 3 contextos implícitos: self, o chamado ‘klass’ e o ponto constante de definição. Yehuda está confundindo self com ‘klass’.

self

self é o self que você conhece. É o receptor padrão de invocação de método. Sempre existe um self.

p self                         # mostra "main"  
  
class Foo  
  def bar(a = (p self)) end  
end  
foo = Foo.new  
foo.bar                        # mostra "#<Foo:0x471004>"  
  
class Foo  
  class Baz < (p self; self)   # mostra "Foo"  
  end  
end

No nível superior, uma instância especial de Object chamada “main” é o self. Onde quer que esteja, você pode recuperar o self a partir da pseudovariável self.

Se você invocar um método sem explicitar um receptor, self receberá essa invocação.

o chamado ‘klass’

Eu chamei o conceito de ‘klass’ no artigo antigo, mas não sei se é o melhor nome. É a classe padrão sobre o qual o método é definido. Agora gostaria de chamá-lo “definidor padrão”.

Ruby sempre segura a referência a uma classe assim como ao self. Mas não há maneira de recuperá-lo diretamente. É mais implícito que self. Se você definir um método sem dar um receptor específico, em outras palavras, se definir um método com o jeito sintático normal de definir métodos, o definidor padrão terá o método como um método de instância.

Exemplos:

No nível superior, Object é a classe. Então funções globais são igualmente métodos de instância na classe Object como você já sabe.

12	def hoge; end Kernel.instance_method(:hoge) #=> #<UnboundMethod: Object#hoge>

Aliás, “hoge”, “fuga”, “piyo” é japonês para “foo”, “bar”, “baz”.

A sintaxe class muda ambos os self e o definidor padrão para a classe que está agora sendo definida.

1234	class T def hoge; end end T.instance_method(:hoge) #=> #<UnboundMethod: T#hoge>

Em um corpo normal de método, self é o receptor de invocação de métodos e o definidor padrão é a classe sintaticamente fora dela, agora ela é T.

class T  
  def hoge  
    def fuga; end  
  end  
end  
t = T.new  
t.hoge  
t.method(:fuga)               #=> #<Method: T#fuga>  
T.instance_method(:fuga)      #=> #<UnboundMethod: T#fuga>

Não confunda isso com def self.fuga, uma definição de método singleton. Quando você dá uma definição de método a um receptor, o método será adicionado à eigenclass do receiver.

U não tem um método de instância chamado fuga porque fuga é um método singleton de u.

Onde quer que esteja, existe um definidor padrão. Quando executa um valor padrão, o definidor padrão é a classe externa assim como no corpo do método.

Em outras palavras, a definição class muda o definidor padrão mas não a definição de método.

família eval

O que o instance_eval faz é:

mudar o self para o receptor do instance_eval
mudar o definidor padrão para o eigenclass do receptor
* se o receptor não tiver um eigenclass ainda, cria um.
executa o bloco dado

o = Object.new  
o.instance_eval do  
  p self                       #=> #<Object:0x454f24>  
  def hoge; end  
end  
o.method(:hoge)                #=> #<Method: #<Object:0x454f24>.hoge>  
Object.instance_method(:hoge)  # raises a NameError "undefined method `hoge' for class `Object'"

Vamos lá:

Como o instance_eval muda o definidor padrão do eigenclass para $o, então fuga e piyo serão métodos singleton de $o

Oops, esqueci de mencionar que:

1	RUBY_VERSION #=> "1.9.1".

Ruby 1.8 age de maneira mais léxica, então você acabará tendo o contrário:

1234	$o.method(:fuga) # raises a NameError $o.method(:piyo) # raises a NameError T.instance_method(:fuga) #=> #<UnboundMethod: T#fuga> T.instance_method(:piyo) #=> #<UnboundMethod: T#piyo>

Em Ruby 1.8, o definidor padrão no corpo do método é baseado lexicamente na definição da classe externa. De qualquer forma, tanto no Ruby 1.8 quanto 1.9, instance_eval muda self para o receptor, o definidor padrão a seu eigenclass.

Finalmente, class_eval muda ambos self e o definidor padrão para o receptor:

	self	definidor padrão
class_eval	o receptor	o receptor
instance_eval	o receptor	eigenclass do receptor

No meu artigo antigo eu discuti sobre Kernel#eval e instance_eval/class_eval com execução de Strings.

definição de constantes

Quando você vê uma variável de instância, ela é uma variável da instância de self. Quando você usa uma variável de classe, ela é uma variável de classe da classe de self; ou o próprio self quando self é uma classe.

Mas constantes se comportam de maneira diferente. É outro contexto implícito de Ruby. O Ruby Core Team chama esse conceito de “cref”.

Discutiremos esse conceito de “cref” em outro artigo.

[Tradução] Metaprogramação em Ruby: é tudo sobre Self

Mon, 16 Nov 2009 10:56:08 PST

Hoje o Yehuda Katz publicou um artigo muito didático sobre metaprogramação em Ruby que achei legal traduzir. Aí vai:

Depois de escrever meu último post sobre idiomas de plugins Rails, eu percebi que metaprogramação Ruby, no fundo, é na realidade bem simples.

Tem a ver com o fato de que todo código Ruby é executado – não há separação entre fases de compilação e runtime, cada linha de código é executado contra um self particular. Considere os próximos 5 trechos de código:

class Person
  def self.species
    "Homo Sapien"
  end
end
 
class Person
  class << self
    def species
      "Homo Sapien"
    end
  end
end
 
class << Person
  def species
    "Homo Sapien"
  end
end
 
Person.instance_eval do
  def species
    "Homo Sapien"
  end
end
 
def Person.species
  "Homo Sapien"
end

Todos os 5 trechos definem um Person.species que retornam Homo Sapiens. Agora considere outro conjunto de trechos:

class Person
  def name
    "Matz"
  end
end
 
Person.class_eval do
  def name
    "Matz"
  end
end

Todos esses trechos definem um método chamado name na classe Person. Então Person.new retornará “Matz”. Para aqueles familiarizados com Ruby, isso não é novidade. Quando se aprende sobre metaprogramação, cada um desses trechos é apresentado de forma isolada: outro mecanismo para colocar métodos onde eles “pertencem”. Na verdade, entretanto, existe uma única explicação unificada de porque todos esses trechos de cóigo funcionam da forma como funcionam.

Primeiro, é importante entender como a metaclasse de Ruby funciona. Quando você aprende Ruby, você aprende sobre o conceito de classe, e que cada objeto de Ruby tem um:

class Person
end
 
Person.class #=> Class
 
class Class
  def loud_name
    "#{name.upcase}!"
  end
end
 
Person.loud_name #=> "PERSON!"

Person é uma instância de Class, então qualquer método adicionado a Class está disponível em Person também. O que não lhes é dito, entretanto, é que cada objeto em Ruby também tem seu próprio metaclass, uma Class que pode ter métodos, mas está anexado apenas ao objeto.

1234	matz = Object.newdef matz.speak "Place your burden to machine's shoulders"end

O que está acontecendo é que estamos adicionando o método speak à metaclass de matz, e o objeto matz herda de sua metaclass e depois de Object. A razão de porque isso não é tão claro é porque o metaclass é invisível em Ruby:

matz = Object.new
def matz.speak
  "Place your burden to machine's shoulders"
end
 
matz.class #=> Object

Na verdade, a “classe” de matz é sua metaclass invisível. Podemos ter acesso a essa metaclass assim:

12	metaclass = class << matz; self; endmetaclass.instance_methods.grep(/speak/) #=> ["speak"]

Até este ponto, você provavelmente está tendo que se esforçar para ter tantos detalhes na cabeça; parece que existem regras demais. E que diabos é isso de class << matz?

Acontece que todas essas regras esquisitas se resumem em um conceito simples: controle sobre o self em uma determinada parte do código. Vamos retornar à um dos trechos que já vimos antes:

class Person
  def name
    "Matz"
  end
 
  self.name #=> "Person"
end

Aqui, estamos adicionando o método nome à classe Person. Quando dizemos class Person, o self até o fim do bloco é a própria classe Person.

Person.class_eval do
  def name
    "Matz"
  end
 
  self.name #=> "Person"
end

Aqui, estamos fazendo exatamente a mesma coisa: adicionando o método name a instâncias da classe Person. Neste caso, class_eval deixa o self ser o Person até o fim do bloco. Isso é perfeitamento direto quando se lida com classes, e igualmente direto quando se lida com metaclasses:

def Person.species
  "Homo Sapien"
end
 
Person.name #=> "Person"

Como no exemplo do matz anteriormente, estamos definindo o método species à metaclass de Person. Nós não manipulamos self, mas você pode ver o uso de def num objeto anexa o método à metaclass desse objeto.

class Person
  def self.species
    "Homo Sapien"
  end
 
  self.name #=> "Person"
end

Aqui, abrimos a classe Person, fazendo o self ser Person pela duração do bloco, como no exemplo acima. Entretanto, estamos definindo um método à metaclasse de Person aqui, já que estamos definindo o método em um objeto (self). Você também pode ver que self.name enquanto dentro da classe Person é idêntico a Person.name enquanto fora dela.

class << Person
  def species
    "Homo Sapien"
  end
 
  self.name #=> ""
end

Ruby dá uma sintaxe para acessar a metaclass de um objeto diretamente. Fazendo class << Person, estamos fazendo o self ser a metaclass de Person pela duração do bloco. Como resultado, o método species é adicionado à metaclass de Person, em vez da classe propriamente dita.

class Person
  class << self
    def species
      "Homo Sapien"
    end
 
    self.name #=> ""
  end
end

Aqui, combinamos diversas técnicas. Primeiro, abrimos Person, tornando self igual à classe Person. Em seguida, fazemos class << self, tornando self igual à metaclass de Person. Quando definimos o método species, ela é definida na metaclass de Person.

Person.instance_eval do
  def species
    "Homo Sapien"
  end
 
  self.name #=> "Person"
end

O último caso, instance_eval na realidade faz algo interessante. Ela quebra o self no self que é usado para executar métodos e o self que é usado quando novos métodos são definidos. Quando instance_eval é usado, novos métodos são definidos na metaclass, mas o self é o próprio objeto.

Em alguns desses casos, as múltiplas formas de atingir a mesma coisa sai naturalmente da semântica de Ruby. Depois desta explicação, deve ficar claro que def Person.species, class << Person; def species, e class Person; class << self; def species não são três maneiras de fazer a mesma coisa que nasceram juntas, mas elas acabam saindo da própria flexibilidade do Ruby em relação a o que o self é em determinado ponto do seu programa.

Por outro lado, class_eval é um pouco diferente. Porque ele recebe um bloco, em vez de agir como uma palavra-reservada, ela captura as variáveis locais ao redor dela. Isso fornece a possibilidade poderosas capacidades de DSLs, em adição a controlar o self usado em um bloco de código. Mas além disso, ele é idêntico às outras construções aqui.

Finalmente, instance_eval quebra o self em duas partes, ao mesmo tempo que dá acesso a variáveis definidas fora dela.
Na tabela a seguir, define um novo escopo significa que código dentro do bloco não tem acesso a variáveis locais fora do bloco.

mecanismo	método de resolução	definição de método	novo escopo?
class Person	Person	mesmo	sim
class << Person	metaclass do Person	mesmo	sim
Person.class_eval	Person	mesmo	não
Person.instance_eval	Person	metaclass do Person	não

Também note que class_eval está apenas disponível a Modules (note que Class herda de Module) e é um sinônimo para module_eval. Além disso, instance_exec, que foi adicionado ao Ruby 1.8.7, funciona exatamente como instance_eval, exceto que ele também lhe permite enviar variáveis a um bloco.

Rubistas.com.br

Wed, 11 Nov 2009 11:22:15 PST

Last night I made available www.rubistas.com.br, a translation fork of the original Rubyists.eu. I thought it’s a great website because of its simplicity on the approach to group together communities and make them easier to find for everyone.

But, I was careless. According to the Creative Commons License I failed to add proper attribution to Rock & Code and Rubyists.EU. So, Rock & Code contacted me. We talked and I agreed to cease and desist both my fork at github and the website.

I was told that the way I wrote the original blog post in Portuguese (already removed) did upset some of the European collaborators. Specially the part that would translate as “… it is nothing more than a Google Maps mashup.” Again, the intention was never to be negative, quite contrary, it was to pinpoint the fact that it would not be difficult for people to collaborate.

So, rubistas.com.br will remain down. I have no plans for it for the time being.

[Off-Topic] Obediência à Autoridade

Sun, 08 Nov 2009 14:50:07 PST

Atualização: 20/11 Atualizei os vídeos pelas versões legendadas em português no Vimeo.

Atualização: 10/11 Acrescentei uma última seção sobre um assunto recente do Fred Brooks.

Nas minhas últimas palestras sobre organizações eu mostro um vídeo do experimento de Asch. Esse experimento demonstra como as pessoas entram em conformidade com um grupo, mesmo sabendo que o grupo pode estar errado. Mas por diversas razões, elas se conformam. Para nós agilistas, pense numa equipe realizando Planning Poker ou Retrospectiva. Quando a maior parte da equipe dá uma resposta, a minoria “tende” a ir com a opinião do grupo. Claro, alguns mantém sua posição mais firmemente, mas não é o normal. O normal é nos conformarmos, e isso deve ser levado em consideração. Assistam para entenderem:

Experimento da Conformidade de Asch from Fabio Akita on Vimeo.

Mais do que isso, nós funcionamos atualmente em organizações com estruturas antiquadas. Hierarquias, cargos, chefes, procedimentos, políticas. Tudo isso – como eu falo nas palestras – não funciona hoje em dia. Elas apenas limitam a organização como um todo. Trás resultados de curto prazo? Com certeza, por isso todos ainda usam. Em longo prazo, cria uma organização doente.

Um dos fatores é a respeito de autoridade. Em organizações desse tipo, quando se tem um “chefe”, o efeito é: “a responsabilidade das tarefas executadas não é do subordinado, mas do chefe que dá a ordem.” É o que todos nós já ouvimos antes: “eu estava apenas seguindo ordens”, ou “eu só trabalho aqui”. Mesmo quando se está executando tarefas hediondas (nazistas torturando judeus, por exemplo), uma teoria é que as pessoas em si poderiam até entender que o que estavam fazendo estava “errado” mas como a decisão da execução saiu de alguma autoridade, nós não sentimos o mesmo remorso ou pensamos melhor em alternativas ou mesmo de simplesmente parar a execução.

Quem demonstrou isso foi Stanley Milgram, nos anos 60. A BBC refez o mesmo experimento e você pode assistir ao meu resumo legendado:

Experiência da Obediência de Stanley Milgram from Fabio Akita on Vimeo.

Estes são todos perigos reais, que acontecem no nosso dia-a-dia:

as pessoas se conformam com muita facilidade
as pessoas não gostam de parecer que estão erradas, portanto não arriscam
as pessoas obedecem autoridades, sejam chefes, sejam pessoas com status maior de alguma forma

Que é um dos motivos pelos quais muitos dos projetos de agilidade, em particular, falham. Não adianta simplesmente dizer: “a equipe decide qual o melhor caminho”, se ainda existe alguém com poder de veto. Se o veto for usado, apenas uma vez, ninguém mais da equipe vai levar qualquer coisa a sério. As organizações atuais limitam as pessoas, limitam seu possível potencial, limitam qualquer chance motivação, limitam a individualização, enfim, transformam as pessoas em robôs. E quanto mais um indivíduo se conforma nessa estrutura, mais ele se torna amorfo, praticamente um pedaço de carne ambulante.

Portanto, a única saída, é eliminar as hierarquias de poder. Assista minha introdução sobre essa idéia na palestra que dei no Rails Summit 2009 (créditos do vídeo para @agaelebe, obrigado por ter filmado):

Organizações, enquanto sistemas clássicos, fechados, tendem sempre a estagnar e entrar em colapso. Pode levar 10 anos, mas é o que vai acontecer, naturalmente. Sistemas complexos adaptativos, por outro lado, tendem a continuar em evolução, aprendendo com as pequenas falhas, refinando seus processos naturalmente. Mas isso exige heterarquias, não hierarquias, grupos formados espontaneamente, com controle descentralizado. Difícil de engolir? Concordo plenamente, por isso mesmo quem hoje está em posições de autoridade deveriam ser um pouco mais literados antes de executar as coisas. Aliás, este é outro ponto:

as pessoas de hoje lidam com o conhecimento de forma superficial: elas preferem “fazer” em vez de “perder tempo” em aprender.

Dan Pink apresentou no TED sobre motivação. Primeiro, relembrando: ninguém consegue motivar pessoas, por isso não tentem. Pessoas se motivam sozinhas ou não se motivam. O máximo que empresas e gerentes conseguem fazer é desmotivá-las. Por isso o principal é parar de atrapalhar. O que o Dan coloca é o óbvio: as empresas continuam usando técnicas arcaicas baseadas mais em folclore do que em ciência. O sistema de recompensas e punições não funciona. Entenda:

TED – Dan Pink – Motivation – Legendado from Fabio Akita on Vimeo.

Ele afirma que as pessoas precisam de 3 coisas para se motivarem: Autonomia – o desejo de controlar as próprias vidas -; Maestria – o desejo de se tornar cada vez melhor no que faz -; Propósito – fazer algo maior do que elas mesmas. O que ele descreve, na realidade, é nada mais nada menos do que Agentes dinâmicos, interativos em Sistemas Complexos Adaptativos. Agentes interagem entre si, cooperam e competem, evoluem ao redor de “Atratores Estranhos” que é o propósito ou identidade do grupo, empresa.

Agilidade é uma evolução natural dos processos antigos de gestão. Organizações Democráticas são o passo de mais longo e mais abrangente numa organização.

Este artigo é apenas uma introdução. Releia meus artigos off-topic dos últimos meses para entender mais aspectos disso.

Fred Brooks

Tive o grande prazer de assistir o Fred Brooks no Latinoware deste ano. Devo colocar que fiquei um pouco frustrado pela platéia não-presente, pois a palestra do Fred, que deveria estar cheia, tinha muito pouca gente, demonstrando que a maioria nem sabe sobre ele ou não tem interesse no assunto, o que é bem triste.

O Fred fez uma palestra a respeito de uns 2 capítulos do livro que está escrevendo. Portanto fica a ressalva que ele não apresentou o conteúdo completo e por isso muitas coisas que eu especular podem estar explicadas nos outros capítulos.

O tema foi sobre a importância de “alguém” que seja a Guia-Mestra de um projeto. Ele afirma que projetos, especialmente os grandes, precisam de um Arquiteto-Chefe ou coisa parecida para manter a integridade do produto final. Ele deu exemplos como o da construção de um avião por equipes separadas, onde haviam pessoas que se comunicavam com elas o tempo todo para garantir que o todo permaneceria integrado e consistente.

Eu concordo com essa explicação. Ela é satisfatória e de fato arquiteturas complexas de sistema não aparecem “do nada” de diversas pessoas ou equipes trabalhando separadas.

Porém, existe um enorme caveat aqui. Dependendo de como você interpretar essa explicação, se você tiver o cargo de “Arquiteto” ou for certificado em “Arquitetura de Sistemas”, pode se sentir altamente justificado por uma celebridade como Fred dizendo que arquitetos são vitais a um projeto. Bem, você está errado.

Um arquiteto é nada mais nada menos do que um líder. Isso não é um cargo. É uma condição ganha por mérito, não por posição, certificação, ordem ou coisa parecida. Um exemplo: a kernel do Linux. Ninguém assinalou o Linus Torvalds ao posto de “ditador benevolente” do projeto, ele simplesmente emergiu de uma necessidade, as pessoas aceitaram sua liderança e, se estivessem muito descontentes, poderiam apenas ter feito um fork e um novo líder assumiria.

Líderes de verdade emergem, não são colocados. À medida que um projeto como esse cresce, outros líderes emergem naturalmente em cada parte do projeto. Surgem o que o Linus chama de seus “tenentes”, pessoas como Andrew Morton já foi.

Isso é importante: não é um posto de autoridade ditado de cima para baixo. É uma condição adquirida de baixo para cima. Mais do que isso, líderes evangelizam seus pontos de vista, convencem as pessoas, até certo ponto até podem obrigar certas posições, mas em última instância, em existindo abuso dessa posição a equipe ao redor pode e deve reforçar seus pontos, seus valores ou ao final de uma briga sem vencedores, escolher por sair do projeto – e não se conformar e continuar, como mostrei acima nos experimentos de Asch e Milgram.

Isso funciona extremamente bem no mundo open source porque justamente se trata de um ambiente distribuído, sem hierarquias fixas, sem cargos fixos, onde as pessoas podem se movimentar entre os diversos setores do projeto, onde existe discussão, onde opiniões são levadas em consideração, onde novas idéias são testadas e experimentadas. É o extremo oposto de como se faz software tradicionalmente numa empresa. Uma descrição mais densa está no clássico The Cathedral and the Bazaar, de Eric Raymond.

Alguém, que se considera capaz de começar a resolver um determinado problema, começa assumindo as rédeas. As pessoas ao redor começam a enxergar valor nisso e podem começar a colaborar. A arquitetura inicial vai sofrendo revisões, mudanças e ela evolui. O “líder” desse projeto, provavelmente o autor, continua garantindo que a visão inicial continua e que mudanças propostas – que podem ser melhores que as suas – sejam devidamente incorporadas, em vez da retrógrada posição “não fui eu quem fiz, portanto não aprovo.”

Entender o mundo open source é a chave para entender sobre agilidade e sobre organizações democráticas. Elas nasceram assim por causa das limitações do ambientes (pessoas espalhadas pelo mundo, voluntários, falta de contato físico, necessidade de manter a integridade do código, etc). E mais, liderança não é chefia. Um líder não tem o direito de apenas gritar ordens. Um verdadeiro líder é um líder servil. Ele colabora e ajuda a equipe, ao contrário de mandar e dizer como fazer. Ele influencia, ele evangeliza, ele tenta expor mais pontos de vista, tenta buscar consenso. Às vezes precisa tomar decisões mais difíceis, como ir contra a maioria para garantir a integridade do projeto. Mas faça isso muitas vezes da maneira errada e a equipe deve demovê-lo de sua posição. Inteligência Emocional, nessa posição, é tão ou mais importante do que mero QI.

Portanto, sim, projetos precisam de visões de integração. Mas, não, isso não justifica pessoas “assinaladas” autocraticamente como os “arquitetos”. Nos melhores projetos, essa posição irá emergir. Se a equipe não tem condição de emergir um líder e é necessário assinalar um, ela já está fundamentalmente quebrada. Boa sorte com esse projeto.

[Off-Topic] Celulares e Aviões

Sun, 08 Nov 2009 12:05:15 PST

Eu estou para escrever sobre isso faz alguns meses. Por acaso surgiu no Twitter

@AkitaOnRails, se você derrubar o avião twittando com esse 3G ligado, vai envergonhar o país inteiro! Rsrsrs!!!

É claro que foi uma piada :-) Mas de qualquer forma me motivou a finalmente escrever a respeito. Trata-se do comportamento das pessoas baseadas em premissas falsas.

Alguns meses atrás, enquanto estava indo para mais um evento, eu – de propósito, como sempre – mantenho meu iPhone ligado. Normalmente coloco em Air Mode enquanto no ar para economizar bateria, mas antes da decolagem eu estava assintindo um video podcast. Aí uma senhora do meu lado resolveu encrencar comigo mandando eu desligar. Obviamente eu ignorei ela. Daí o que ela fez? Chamou um comissário de vôo. Afe.

Ela ainda soltou o que muitos ignoramentemente ainda acreditam: “este ‘senhor’ está arriscando a minha vida!” Imaginem minha vontade de soltar um “shut the fuck up!”, claro não soltei :-)

Imagino que leitores do meu blog não acreditam nisso, mesmo assim muitos não devem saber porque esse aviso existe nos aviões. É só raciocinar. Se um eletrônico wireless pudesse realmente ter alguma mínima chance de interferir com a comunicação do avião, a ponto de derrubá-lo, você, se fosse o dono da companhia aérea, permitiria que alguém entrasse com um celular no seu avião??

É a mesma coisa que deixar alguém entrar com uma bomba e apenas pedir educadamente “pedimos aos passageiros que carreguem bombas, para não ativá-las enquanto dentro do avião.” Duh! O fato de podermos entrar com eletrônicos no avião é prova de que nenhum desses equipamentos coloca o avião em risco. Seria burrice. Se realmente derrubasse, todos os celulares seriam obrigados a ir despachados num container de chumbo, assim como não permitem entrarmos com objetos pontiagudos ou coisas do tipo.

Portanto, se não faz mal nenhum, porque mesmo assim essa maldita mensagem ainda toca antes de decolarmos e antes de aterrissarmos? Agora é uma conclusão baseada em indução. Quais os dois momentos mais críticos de um vôo? Sim, decolagem e aterrissagem. São exatamente os momentos que a tripulação gostaria que os passageiros estejam mais prestando atenção a qualquer mensagem de emergência. Agora, se todo mundo estiver com fones de ouvido, jogando seus videogames, teclando nos seus laptops, uma mensagem de emergência demorará bastante até todos entenderem. Portanto, o objetivo principal de mandar desligar os equipamentos é única e exclusivamente para conseguir nossas atenções. Nada mais.

Aí, minha teoria da conspiração é: se você apenas dissesse a verdade: “para termos sua atenção em casos de emergência, pedimos para desligar seus equipamentos”, ninguém desligaria. Por isso deve ser melhor usar a burrice coletiva a seu favor e dizer “pedimos que desliguem seus celulares, videogames, mp3 players, computadores e não basta deixar em modo de avião.” Ou seja, implicitamente usando o medo da interferência de sinais para que os próprios passageiros perturbem os outros – como aconteceu comigo – gerando um peer pressure que obriga os outros a desligar, só para não se dar ao trabalho de discutir.

Aliás, se isso tudo fosse mesmo verdade, eu jamais entraria num avião. Pessoas com más intenções existem, porque confiar que elas desligariam? Aliás, eu não entenderia porque trabalhar num avião sabendo que os passageiros são um risco. Imaginem!

Portanto, sim, se você acredita que sinais de celular podem derrubar um avião, você continua sofrendo de preguiça mental como falei no meu artigo anterior. Se ainda assim quiserem mais detalhes, por acaso achei hoje um episódio do Mythbusters exatamente sobre isso.

Equipamentos eletrônicos não derrubam aviões. As companhias aéreas estão, espertamente, usando seu medo gerado pela ignorância coletiva. Estratégia inteligente.

Ah sim, e embora isso não sirva exatamente como prova, testei isso em quase todos os meus vôos e mantive meu iPhone e iPod ligados durante o vôo :-P Não vi o avião caindo em nenhuma dessas vezes, obviamente. Mas, claro, eu estou sempre prestando atenção na decolagem e aterrissagem, porque entendo o princípio, o resto é só pela experimentação.

[Off-Topic] O problema das credenciais

Wed, 04 Nov 2009 15:21:41 PST

Não é de hoje que todos sabem que eu sou um forte proponente contra certificações, especificamente na área de Informática. Apesar da intenção em si ser boa, o efeito prático é mais danoso que os benefícios. Como dizem, “de boas intenções o inferno está cheio.”

Porém, eu iria mais longe e colocaria um termo guarda-chuva. Na realidade eu sou totalmente contra “Credenciais”, em geral, particularmente fora de contexto. E além disso, eu também gosto de argumentar sobre argumentação. Não é de hoje que menciono sobre falácias sempre que posso. Estou muito longe de um entendimento mais amplo, mas estou sempre tentando expandir essa compreensão e acho que todos deveriam.

Um exemplo simples: eu adoro o trabalho de um Martin Fowler, ou de um Robert Martin. Acho que seus insights são muito valiosos, suas recomendações são excelentes. Com certeza são pessoas que se esforçam para serem acima da média. Porém – e aqui vem o problema – eles também são seres humanos e, como tais, tem defeitos. Isso é um fato, indiscutível, que precisamos assumir em toda argumentação. Simplesmente porque um Uncle Bob disse alguma coisa, isso não configura automaticamente verdade.

Deveria ser óbvio, mas muitas pessoas se “deslumbram” com celebridades. Sério, viram literalmente “cheerleaders”. Ou seja, porque o cidadão trabalhou em alguma empresa de renome, ou porque escreveu um livro, ou simplesmente porque é um gringo, qualquer coisa que ele disser passa a ter peso de verdade. E isso é um enorme perigo. Tudo que os grandes nomes falam precisam passar pelo mesmo escrutínio que alguém sem renome diga. Sem exceções. Eu repito muitas das coisas que um Fowler diz, não porque o considero “a autoridade suprema” no assunto, mas porque o que ele diz efetivamente faz sentido, pode ser experimentado, discutido e, mais importante, abre caminho para ser refinado e evoluído.

Isso é nada mais, nada menos do que a falácia de argumentação por autoridade. Por que A disse B; e porque A é considerada uma autoridade; portanto B é verdade. Prestem atenção: usa-se isso todos os dias. Isso e mais uma dezena de outras falácias (vide lista abaixo) são usadas diariamente e nós caímos nelas o tempo todo.

O contrário também é verdade, só porque o Philippe Kruchten ajudou a criar o RUP não quer dizer que ele seja ruim (brincadeira, o cara é muito bom). Aliás, isso é outra coisa que me incomoda muito: atacar alguma tecnologia, prática ou coisa assim atacando o seu criador ou participante. Por exemplo, “Rails é ruim porque o David é arrogante”. Isso é uma falácia e é bem conhecida em inglês como falácia Strawman (“homem-de-palha”) que em forma mais genérica é falar de um assunto irrelevante para tirar a atenção de discutir o assunto principal.

Ambos os casos são ruins. Isso nos leva à tendência também de ignorar as pessoas sem renome, seu funcionário mais experiente, que efetivamente entende do problema, às vezes é ignorado, porque alguém de mais renome – mas totalmente fora do contexto – lançou certas “verdades”. Agora essa “verdade” é a lei. Sem mais perguntas. E, claro, o contrário também existe: você só acredita no seu funcionário mais antigo justamente porque é o mais antigo. Nada disso são boas justificativas. O importante sempre é: não interessa a pessoa, interessa sim seus argumentos. E argumentos que sigam o método científico.

O fato é que a maioria de nós temos preguiça de pensar. Pura e simples preguiça. Além disso, a forma como fomos criados sempre trás figuras de autoridade e essa figura sempre tem mais razão do que nós – um sinal de baixa auto-estima, eu diria. Portanto, quando vemos alguém em posição de autoridade, a tendência é aceitar o que vem dela, especialmente se estamos confortáveis com seu entendimento – o velho problema de sair da zona de conforto. A maioria das pessoas não foi treinada para mudanças, foi treinada para estabilidade, por isso qualquer coisa diferente sempre é vista com maus olhos. A maioria apenas ouve aquilo que quer ouvir, só vê aquilo que quer ver. Ninguém de fora consegue mudar isso facilmente em outra pessoa, o que é bem triste.

Veja alguns artigos da Wikipedia sobre o assunto de argumentação:

Uma pessoa que não gosta de argumentar, por definição, não pode jamais ser tomadora de decisões. Muitos usam de credibilidade dos outros de forma inadequada (“porque fulano disse – fora de contexto, mas disse …”). Mas o pior é quando uma decisão é tomada no grito, por força do cargo, por exemplo. Essa é a atitude de um indivíduo com claras incapacidades de argumentação e, portanto, de compreensão do assunto.

Claro, em muitas ocasiões somos forçados a decidir alguma coisa “por instinto”. Se ficássemos o dia todo argumentando cada pequena decisão realmente não faríamos nada. Imagine argumentar se devo vestir a camisa vermelha ou amarela e porque. Não estou falando de micro-argumentação (que, assim como micro-gerenciamento, não funciona). Porém, decisões que envolvem pessoas, pontos de vista divergentes, devem ser analisados com mais calma. Se mesmo depois da argumentação ainda não for possível tirar uma conclusão lógica de nenhuma das duas premissas, no fim é o instinto que vai acabar guiando a possível solução. Argumentação não é uma ciência-exata, é humanas utilizando princípios científicos para uma melhor formulação de argumentos.

E ainda no caso de falácia, muitos ainda acreditam na “ditadura da maioria” ou “porque a maioria disse que algo é verdade é porque deve ser”. Uma das formas falaciosas é descrita como argumentum ad populum, ou aquele jeito malicioso de se começar uma frase: “Todo mundo sabe que …” Eu sempre digo que admiro os pais fundadores da América por terem tido insights avançados para a época que até hoje as pessoas não entendem direito. Citando Thomas Jefferson, temos:

Todos, também, devem ter em mente este princípio sagrado, que embora a vontade da maioria deva prevalecer em todos os casos, essa vontade de ser correto deve ser razoável; que a minoria possui direitos iguais, que leis iguais devem proteger, e violar isso seria opressão.

Portanto, também não é “em todos os casos a maioria vence” mas sim “em todos os casos que não violam os direitos da minoria, a maioria vence”. Isso é sutil. Por exemplo, porque a maioria decidiu que devemos tirar sua propriedade, portanto isso está correto. Não, porque cada indivíduo tem o direito à sua própria propriedade e o governo deve protegê-la. Assim, a vontade da maioria de retirar a propriedade de alguém é revogada pelo fato de um direito fundamental estar sendo violado, o que se configura, por definição, como opressão, não como democracia.

Pensar é difícil, demanda estudo, demanda cultura, demanda prática. Pensar com afinco não é algo que a maioria das pessoas “ocupadas” tem vontade de fazer. A maioria prefere que lhe dêem as respostas prontas e enlatadas, ou então prefere escolher qualquer coisa rapidamente “por instinto”, ou “porque eu já escolhi certo antes, portanto vou escolher certo sempre” ou ainda “porque já funcionou antes em algum lugar, deve funcionar aqui também”, o que, obviamente é uma falácia, a boa e valha Post hoc ergo propter hoc

Aliás, a “Post hoc ergo propter hoc” é o motivo de porque livros de auto-ajuda, livros com metodologias mágicas, receitas “avançadas” e todo tipo de procedimento enlatado vende tanto: porque retira o trabalho de pensar das pessoas, lhes dando respostas prontas, “que já funcionaram em dúzias de lugares”, ou coisa parecida.

Algumas efetivamente, depois de pesquisa e experimentação prudente, são boas mesmo. A maioria, no entanto, me lembra uma alegoria, sobre de medicina. Imagine, se todos os médicos agissem assim. Você entra no consultório do médico e diz:

- Doutor, estou com muitas dores.
- Meu filho, tome este remédio todos os dias e a dor acaba. Pode ir embora.
- Mas Doutor, o senhor não vai nem me examinar, me diagnosticar?
- Pra que? Já dei este remédio para os últimos 3 pacientes que passaram e todos melhoraram, porque vai ser diferente com você?

Engraçado? Não deveria ser. Reveja as decisões que você toma, ou que pessoas ao seu redor tomam, e vai notar que elas se parecem muito com essa alegoria. Aliás, se parecem muito com a maioria dos argumentos falaciosos que menciono neste artigo. Eu mesmo me pego caindo nesse tipo de truque, muitas vezes. Mesmo a pessoa mais policiada ainda cai. Argumentação é uma arte. Compreensão também.

Portanto, a única coisa a se fazer é o que eu digo o tempo todo: ~~Seja Cético.~~ Questione, sempre, o Status Quo.

[Off-Topic] Saúde

Sun, 01 Nov 2009 18:17:58 PST

Atualização: 03/11

Finalmente, depois de mais de 5 anos sem atividade física significativa, terminei minha primeira sessão de exercícios físicos aqui em casa. O equivalente a 6Km em corrida a passo médio no meu elíptico, depois uma sessão anaeróbica com halteres pros braços. Ainda estou suando.

Este último ano me deixou fisicamente e psicologicamente quebrado, quase sem eu perceber. Nunca fiz tanta pesquisa, e a parte frustrante de pesquisa é que para chegar a uma conclusão de um parágrafo, às vezes isso significa meses de noites mal dormidas, lendo, lendo, lendo.

Isso sem contar as dezenas de eventos que participei este ano. A grande maioria das minhas palestras – que não deixam de ser parte da minha pesquisa – consumiram quase todos os meus fins de semana e feriados. Foram alguns poucos dias que usei durante o horário comercial para terminá-las.

Com isso, meu ritmo diário ficou em torno de dormir diariamente lá pelas 4 da manhã, acordar lá pelas 9 ou 10 horas, 7 dias por semana. Sem contar os episódios de varar noite, que foram alguns durante o ano. Esse ritmo tem apertado bastante nos últimos 3 anos.

Sit mens sana in corpore sano

Hoje estou com mais de 75kg e 1.72m de altura. Não preciso de um índice pra saber que estou fora de forma. Os “pneus” já se acumularam, os músculos estão fracos, a resistência física em geral está baixa. Até 2003 eu era mais pesado e mais fora de forma, estava com 78kg para mais. Em 6 meses de esteira diária, média de 6km por dia, mais exercícios anaeróbicos, otimização na alimentação – redução drástica de gordura, carboidratos – eu cheguei a menos de 70kg. Literalmente precisei refazer meu guarda-roupa.

Porém, depois de 2004 esse ritmo já decaiu, o trabalho na consultoria ficou mais pesado, os clientes ficaram mais estressantes, e no fim de 2005 ainda resolvi começar com esse negócio de “Rails” :-) Aí já era.

Mas agora já foi longe demais. Minha meta é, até o fim deste ano, voltar perto dos 72kg. Só que não é “apenas” perder 3kg. 3 é um saldo. Eu preciso perder muito mais do que isso de gordura ao mesmo tempo que substituo por músculo. Em breve preciso regular a dosagem diária de carboidratos e aumentar um pouco mais o consumo de aminoácidos, fora outros suplementos. Já fiz isso antes e acredito que não será tão difícil assim. O objetivo principal é melhorar a resistência física geral.

Programadores, no geral, dão pouca atenção a isso. De fato, há tanta coisa que se pode fazer nas horas vagas, novos projetos open source, novos livros, blogs e mais blogs, artigos técnicos. Fora jogos, YouTube, Facebook. É bem difícil se desconectar. Porém, o espelho vem me deixando mais e mais frustrado o que, por sua vez, piora o ciclo vicioso de me manter online. Programadores precisam ter vaidade para aumentar mais a auto-estima, e vaidade significa boa aparência, isso ajuda a retirar o ar introspecto e facilita a socialização. Inicia-se um ciclo virtuoso.

Melhorar a forma física, novamente, não é algo que se faz com uma receita (como eu sempre digo, joguem fora as drogas como “emagraça em 7 dias”). Assim como a decisão de se tornar um bom programador, superando a média de aprendizado, também é preciso ter a atitude de querer superar as limitações físicas, ter sempre na cabeça o pensamento de “ainda falta mais, ainda preciso me esforçar mais.” Como eu já passei por academias antes, já tive uma rotina de exercícios, ainda sei como regular meu ritmo. Se você nunca fez isso, acredite, vai doer, vai ser difícil, e depois de poucos dias a vontade de desistir é enorme. Desculpas começam a se amontoar e a maioria efetivamente se convence de que não precisa se esforçar tanto. É o que explica como as academias ganham dinheiro: faça o indivíduo assinar 6 meses, ele vai treinar por 2 semanas, depois vai desistir. Menos de 3 meses de rotina ainda é considerado tempo para desistência. Só quem consegue manter mais de 6 meses de rotina pode começar a imaginar que está conseguindo. E se exercitar de fim de semana não é exercício.

Hoje foi mais um primeiro dia para mim. Eu acho que já fiz isso umas 4 vezes nos últimos 10 anos. Estou começando a ganhar experiência nisso, o que não é exatamente razão de orgulho. Estes 2 últimos meses do ano serão um “warm-up”. O objetivo de 2010 é manter a rotina de exercícios diários o ano inteiro. Mas há um truque: acrescentar esta rotina de exercícios e aumentar minha rotina de pesquisa, ou seja, isso não poderá ser desculpa para diminuir meu trabalho em casa. Sem desafio não tem graça. Portanto o lance será otimizar mais meu tempo. Novamente, não há receita para isso. Nada de GTD ou receitas da moda desse tipo. Significa otimizar cada micro-decisão durante o dia.

E, claro, “bombas” não funcionam. É como as metodologias da moda aplicadas da forma errada: dá efeito rápido, satisfação imediata, mas acumula efeitos colaterais de longo prazo que, também rapidamente, levam à destruição. Evite resultados rápidos. Por isso também virar um vegetariano ou vegan não é nem de longe uma opção. A opção é diminuir gorduras e aumentar proteínas, além de balancear as fontes de vitaminas. Nada mágico nisso. Da mesma forma, evite os “gurus”: nunca funcionam. Entenda os fundamentos e aplique os melhores exercícios às suas circunstâncias particulares. E para me forçar mais um pouco, eu sempre tenho o seguinte fundamento: “uma pessoa que não consegue sequer gerenciar sua própria forma física, não pode ter a pretensão de achar que pode gerenciar os outros.”

Uma curiosidade para quem acompanha meus off-topics sobre gerenciamento: aumentar a massa muscular é um processo de destruição. Exercícios como levantamente de peso foram feitos para, literalmente, “rasgar” os músculos. Por isso mesmo, para quem está começando, recomenda-se fazer esse tipo de exercício em dias alternados. Num dia você destrói seus músculos, no outro ele se reconstrói e aumenta um pouco mais para aguentar a carga. Por isso também é importante melhorar o metabolismo de proteínas. Aumentar músculos, portanto, não é um processo de apenas acúmulo. É sim, um processo de pequenas destruições e reconstruções. Pense nisso.

Finalmente, este blog post tem o único objetivo de me ajudar a focar no objetivo. Por alguma razão, dá impressão de que estou assinando um compromisso :-) Espero que consiga cumprí-lo.

Esclarecimento sobre “Perda de Peso”

Só para ficar mais claro: “perder 3kg” não é um objetivo. Um cuidado que precisa se tomar é que a frase “perder peso” é muito errado. O certo seria dizer: “perder gordura e aumentar massa magra”, ou seja, queimar gordura e aumentar músculo. Normalmente as duas coisas juntas não combinam muito bem.

Algumas coisas que são importantes: para quem é sedentário, completamente destreinado, ao começar a fazer exercícios já se tem uma satisfação imediata de perda de peso e um pouco de aumento de massa magra – a menos que você tenha problemas hormonais ou coisa assim -, isso é natural, mas tende a diminuir e vai ficando cada vez mais difícil queimar gordura e aumentar músculo.

Tem que se tomar cuidado porque gordura não é fácil de queimar (nosso organismo evoluiu milhares de anos para manter reservas de energia para épocas de escassez, queimar gordura, do ponto de vista do organismo, é algo “ruim”).

Além disso, a primeira coisa que você queima nunca é gordura, e sim carboidratos. Em exercícios aeróbicos como correr, os primeiros 20 min iniciais são queimando carboidratos, só depois é que se começa a queimar gordura. E pior: massa muscular é mais fácil de queimar do que gordura. Para ter resultados realmente efetivos o correto é consultar um nutricionista e criar uma dieta controlada, além de um bom instrutor que saiba controlar seus exercícios aeróbicos e anaeróbicos, frequencia, carga, etc.

Uma das primeiras coisas – e agora é apenas opinião de leigo, consulte seu nutricionista – é diminuir a quantidade de carboidratos, bastante (o mais difícil: massas, doces). Não é zerar, mas diminuir bem. Não precisa deixar de ingerir gorduras, basta não abusar. E precisa comer carnes para suprir proteínas. Fora as vitaminas e fibras. Além de dividir mais sua alimentação: pequenas quantidades 5 ou 6 vezes por dia. Eu mesmo ainda não vou conseguir seguir uma dieta mais rigorosa, vamos ver.

A balança normal não é um bom indicador de melhoras: diminuir de peso (o saldo) pode significar que você está desidratando (perdendo apenas água), perdendo massa magra (literalmente perdendo músculo). Por isso precisa entender um pouco mais dos princípios antes de simplesmente apenas fazer qualquer exercício.

[Rails Summit 2010] Commence Planning

Thu, 29 Oct 2009 21:39:14 PDT

Railers all around the globe, I am very happy to report that the Ruby on Rails community in Brazil is growing strong. Last 13, 14th of October we had Rails Summit Latin America, with 550+ attendees we had the 2nd edition of the second largest Rails conference in the world after the official RailsConf.

This conference is possible thanks to Locaweb, the largest hosting company in South America. Together, we were able to organize two very successful events. When I started being a Rails activist back in 2006, with virtually no rubyists in Brazil, I never imagined how far we would be able to go. Now we have a healthy ecosystem, with some great recognized open source programmers, some small consultings starting to pop up, a few startups starting to show up, even some ‘enterprisey’ companies coming to adopt it. The Brazilian Rails community is a force to be reckoned.

There’s a lot more to do though, and I am again counting on the international rubyists support to keep on going. The last 2 Rails Summits were real challenges, and we will strive to continue to deliver the best conference in South America. Up to this year’s edition I had to have closed speakers list, but for 2010 I will finally be able to have an open Call for Participation, and I hope Railers all around the world show interest to come visit Brazil, get to know our beautiful country and meet our friendly people. I will let you know the details next year, as soon as I can.

Rails Summit gets inspiration from the official RailsConf. The format of the conference comprises 2 full days, with 2 parallel tracks, a Lightning Talk session, real-time translation from English to Portuguese and Portuguese to English, rooms with power plugs and ubiquitous wireless internet access. Up to this year we used the Elis Regina auditorium, inside the Anhembi Convention Center area, in São Paulo City. For next year we will move it to Frei Caneca Convention Center, which is also in São Paulo City, nearer the famous Paulista Ave. area, much more convenient to find hotels and entertainment areas. I think you will enjoy it. Prices will be around USD 140 for the same 2 full days of event. Above, you can see 2 photos from one of the other conferences that Locaweb does in the Frei Caneca Convention Center.

We recorded all the talks from this year’s edition and I will release them as soon as possible, so you can see how it was. Follow me on twitter or subscribe to this blog’s feed. I’ll keep you posted.

[Rails Summit 2010] Iniciando o Planejamento

Tue, 27 Oct 2009 16:36:52 PDT

Atualização 28/10: atualizei a estatística e pensando melhor, as conclusões são um pouco diferentes.

Atualização 29/10: coloquei algumas fotos do Frei Caneca.

Um evento do porte do Rails Summit não se faz da noite para o dia. Em 2008 a Locaweb assumiu o risco e juntos fizemos um evento de escala internacional em apenas 3 meses. Isso facilmente se traduziria em suicídio, mas acho que conseguimos um excelente resultado, dadas as limitações logísticas.

Para este ano, começamos meses atrás. O auditório Elis Regina foi alugado já no fim de 2008. Os palestrantes internacionais foram contactados logo depois da RailsConf 2009, em Las Vegas. Marketing, patrocínios, fornecedores, foi tudo planejado de antemão pela equipe de eventos da Locaweb. Por isso este ano, comparado com o ano passado, foi bem mais sossegado.

Mas ainda temos algumas dúvidas não solucionadas. Por isso ontem lancei um twit com uma primeira mini-pesquisa. Ficamos surpresos que a reação foi bem rápida! Em meros 5 min mais de 100 respostas foram coletadas. Neste momento já temos mais de ~~330~~ 464 respostas. Com isso, eu compilei este resultado parcial:

O Elis Regina é um excelente local, espaço amplo, bom para a comunidade socializar. Por outro lado ele é contra-mão para a maioria das pessoas. Fica longe do centro da cidade, ou seja, longe da maior parte dos hotéis. Fica longe dos pontos de baladas, bares. Fica longe do transporte público principal como metrô. Além de ser um dos locais mais caros de São Paulo para se fazer eventos.

Em vista disso, estamos considerando o Centro de Convenções do Shopping Frei Caneca que, para quem não conhece, fica no bairro Cerqueira César, uma região razoavelmente próxima à Avenida Paulista. Ou seja, próximo a metrô, a hotéis, bares, etc. Como fica no topo do Shopping Center, existe uma ampla praça de alimentação, o que nos economiza o problema de comida (vocês não tem idéia da dor de cabeça). Por outro lado, o espaço para socializar e fazer atividades paralelas como dojos, é menor.

Outra coisa é sobre os dias do evento. Pessoalmente eu achava que os melhores dias seriam sexta e sábado, para ter domingo para descansar e para ficar mais fácil de convencer a empresa a liberar. Nós sempre fizemos no meio da semana, por experiência do pessoal de eventos. Mas olhando no gráfico vemos o seguinte: 1) quem já participou prefere durante a semana; 2) quem nunca participou prefere de sábado e domingo; 3) sexta e sábado perde nos dois. É quase um empate técnico entre dia de semana e sábado-domingo. Pensando melhor, acho que faremos durante a semana mesmo, preferencialmente numa quarta e quinta, porque sexta sempre tem trânsito pior e as condições para um evento são piores, historicamente.

Eventos a preços baratos (próximo ou abaixo de R$ 50) são muito fáceis de encher. Mas eventos acima de R$ 200 já são considerados investimentos. Por isso mesmo ainda é complicado falar em sair de São Paulo. Dificilmente daria para encher mais de 500 pessoas a preços acima de R$ 200 fora daqui. Pelo menos não temos nenhum dado que indique o contrário.

Por enquanto, consideramos fazer a conferência no Frei Caneca, provavelmente numa sexta e sábado. Ao preço de R$ 250 fixo, sem opção para estudantes (que é algo que só o Rails Summit fez, praticamente nenhum outro evento tem isso). A maioria não dá conta disso, mas R$ 400 é um preço muito abaixo do preço de custo do evento. O Elis Regina, palestrantes internacionais, alimentação (2 almoços, 4 coffee-breaks), encarecem bastante o custo total. Essas mudanças todas ajudam a baixar bastante esse custo mantendo a qualidade geral.

Não haverá mais preço especial para estudantes. Aliás, a maioria das conferências não tem isso, nos dois últimos anos eu pedi para colocar, mas não vale a pena. Fazendo no Frei Caneca, podemos reduzir o preço, isso já tornará o evento mais acessível e sem necessidade de mais descontos.

Eu sei que muitos gostariam do evento em outros estados. Eu ouvi especialmente Rio de Janeiro e Porto Alegre. Pessoalmente, minha escolha é o Rio de Janeiro, sem sombra de dúvidas, pelas possibilidades de turismo e tudo mais. Mas, falando de forma realista, é muito difícil de justificar. Só de curiosidade, acima está o gráfico de participação relativa por estado. O que sabemos, comparando com outros eventos que participamos e organizamos, a logística é muito diferente. Fora de São Paulo, existem poucas alternativas de fornecedores, o custo para organizar é maior. Eventos menores são menos difíceis, mas um do porte do Summit é mais complicado. E infelizmente é uma realidade que a população de São Paulo é pelo menos uma ordem de grandeza superior a qualquer outro lugar e esse tipo de conferência depende de uma quantidade maior de pessoas do que o normal. Somente eventos do tamanho de um FISL conseguem movimentar pessoas para fora de São Paulo.

Além disso, eu ouvi e li diversos feedbacks e estou considerando tudo para melhorar ainda mais o conteúdo do ano que vem. Uma das coisas que finalmente vou conseguir fazer é um Call for Participation, ou seja, alguns palestrantes eu mesmo vou pré-selecionar, mas a maioria dos slots serão preenchidos via propostas enviadas a mim por palestrantes de qualquer lugar do mundo. Daí eu farei a seleção e isso deve tornar a programação mais diversificada. Se você se interessa, comece a pensar no assunto. Ano que vem vou colocar as regras e datas no ar. E ainda teremos também a Desconferência, possivelmente de forma mais organizada e com tempo mais rígido que nos últimos dois anos (na RailsConf, o microfone é desligado por um timer, por exemplo).

Acima estão algumas fotos do Encontro Locaweb que fizemos no Frei Caneca. Nesse caso estamos usando o auditório aberto, com 900 pessoas. Esse dá para ser dividido em 2 para fazer mais de uma sala.

Bom, ainda é cedo. Estamos avaliando as opções. Ano que vem traremos as novidades o mais cedo possível.

[Rails Summit 2009] Retrospectiva

Sat, 17 Oct 2009 16:06:16 PDT

Finalmente acabou, a segunda edição do Rails Summit 2009. Novamente tivemos aproximadamente 550 participantes, 20 palestrantes. Num ano de “semi-crise” (ou seja lá como estão chamando isso), foi um bom resultado.

Tive a impressão que vieram mais pessoas de mais lugares fora de São Paulo. Claro, os cariocas vieram em peso, praticamente um arrastão :-) Foi ótimo ter todos eles juntos depois do #devinrio. O pessoal do Norte estava presente com o Paulo Fagiani, o Elomar e, claro, seu irmãozinho Aldo. Veio pessoal do Sul, do Nordeste, do Centro-Oeste. Além deles vieram meus amigos da Argentina, que não vejo desde o Locos x Rails que participei no começo do ano.

Os Brasileiros, novamente, deram um show de hospitalidade e camaradagem, teve #horaextra todos os dias. No primeiro dia foi no Bar Brahma, no segundo dia foi no Villa Vintém, eu sei que ontem ainda saíram novamente. É o tipo de coisa que não acontece nas RailsConf. Espero que todo mundo tenha aproveitado para fazer novos amigos, conseguir mais contatos e voltar mais inspirados em cada região para fortalecer as comunidades locais.

Os Bastidores

Escolhemos o mesmo local do ano passado, o auditório Elis Regina, no Anhembi. Porém, ano passado as coisas foram feitas com muito mais pressa. Em 2008, começamos a organizar o evento em julho, para ser lançado em outubro, ou seja 3 meses efetivamente para fazer tudo. Foi bem difícil, mas a equipe de eventos da Locaweb fez um excelente trabalho. Este ano começamos a olhar isso com muito mais antecedência. Por exemplo, o website ficou pronto em julho, sendo que no ano passado ele só foi pro ar em setembro.

Mesmo assim, os dias que escolhemos – 13 e 14 de outubro – foram difíceis de pegar. Tentamos já alugar em novembro do ano passado e mesmo assim a agenda de 2009 do anhembi já estava lotada, tinham poucos slots pra pegar. Ano passado concorremos na mesma semana do Microsoft TechEd e este ano concorremos com o Futurecom.

Dos problemas do ano passado, resolvemos todos os principais:

o calor do auditório B, que foi bem ruim no primeiro dia, mas resolvemos desta vez tendo de antemão nada menos do que 16 ar condicionados. Acredito que desta vez ninguém passou calor.

o espaço apertado e o pé-direito baixo do auditório B foram resolvidos também, com uma sala que era quase o dobro do tamanho e altura do que o do ano passado. Para isso alugamos um espaço muito maior, o que também proporcionou um restaurante muito melhor e que gerou quase nenhuma fila na hora do almoço, nenhum aperto, e também muito menos calor.

com o auditório B maior também conseguimos colocar uma cabine de tradução decente e tivemos tradução simultânea de português-inglês e inglês-português nos dois auditórios. Uma reclamação justa no ano passado foi a divisão de americanos no auditório maior e brasileiros no menor. O problema foi logístico mesmo. Pior porque ano passado tínhamos tradução para espanhol. Este ano eu resolvi não ter tradução pra espanhol (quem viaja até o Brasil pro Summit com certeza sabe inglês). Assim conseguimos dividir e colocar americanos também no auditório B.

Cerca de 3 ou 4 meses antes do evento já estávamos em contato com todos os palestrantes internacionais para acelerar o processo de vistos que sempre é um problema. A intenção era que eles também se adiantassem, mas muitos deles empurraram com a barriga e deixaram para a última hora. Por isso tinha palestrante que só pegou o visto alguns dias antes do evento, seja porque demoraram, ou seja porque o consulado demorou mesmo.

E ao contrário do ano passado, este ano tivemos muito mais problemas com os palestrantes internacionais. Primeiro o Justin Gehtland não conseguiu tirar o visto a tempo. No lugar dele deu tempo de colocar o Carlos Villela. O mesmo problema aconteceu com o Jason Seifer, mas felizmente ele ia palestrar em dupla com o Bruno Miranda e por isso deu pra manter a mesma palestra. Finalmente, na última hora, o Bryan Liles ficou com suspeita de gripe suína e também não pôde vir, mas como ele ia palestrar em paralelo comigo, acabei fazendo minha palestra ser um keynote.

Fora isso o Ilya Grigorik e o Chad Fowler tiveram problemas com atrasos nos vôos, mas pelo menos eles vieram antecipadamente. O Gregg Pollack aterrissou em São Paulo lá pelas 8 da manhã, sendo que ele ia palestrar às 10:30, então foi bem corrido. O Matt Aimonetti teve o vôo dele cancelado pela Delta Airlines! Felizmente ele conseguiu se virar e arranjar outro vôo e chegou na hora do almoço, sendo que a palestra dele ia fechar o primeiro dia! Haja coração!

Este ano, felizmente, tivemos mais patrocinadores que o ano passado, também começamos a procurá-los com muito mais antecedência. Mais legal ainda porque tivemos três empresas que efetivamente usam Rails: a Caelum, a GoNow e a ThoughtWorks. Sem revelar valores, este ano conseguimos gastar menos do que o ano passado e ainda conseguimos entregar mais. Aprendemos muito. Mesmo assim, a Locaweb ainda foi a maior patrocinadora deste evento, pagando aproximadamente 1/3 do valor total. Para quem estava curioso, não, o evento não foi feito para dar lucro. Mas não significa que podemos gastar quanto quisermos – não podemos -, por isso estamos já planejando o que podemos fazer para diminuir esse custo sem sacrificar muito da qualidade e ainda manter o evento viável.

Outro problema inesperado que não tivemos no ano passado foi o serviço dos terceirizados de som. No primeiro dia tivemos diversos problemas espalhados pelo dia, como chiado, microfonia, microfone que desligava do nada, etc. Vocês devem ter sentido parte desse problema, nos bastidores estava literalmente um “pega-para-capar”. Mas corremos para ajustar isso, e no segundo dia acho que não tivemos nenhum problema de microfones. O trabalho nos bastidores é bem pesado. Para que os participantes achem que tudo está correndo de forma suave, alguém está puxando muito peso por baixo dos panos :-) Eu só fiz isso agora no Summit, é preciso parabenizar a equipe de eventos da Locaweb que faz essa correria o ano inteiro.

Palestras

Ano passado algumas pessoas reclamaram porque as palestras focavam muito ou em testes ou em temas motivacionais. Eu acho importante que os keynotes sejam mais motivacionais. Por outro lado, foi por pura coincidência, mas de fato tivemos muitas palestras sobre o tema de testes. Este ano tentei tomar mais cuidado para escolher os palestrantes e acho que, no geral, deu uma boa mistura de temas para agradar à maioria.

Tanto o Chad Fowler quanto o Obie Fernandez fizeram palestras especificamente direcionadas ao público brasileiro. O Chad levou em consideração que, diferente dos Estados Unidos, a adoção de Ruby on Rails está só começando aqui no Brasil. Por isso mesmo o tema foi sobre “Insurgência Rails”, ou seja, estratégias para tentar colocar Rails, gradualmente, dentro da sua empresa.

O Obie palestrou sobre um tema que eu particularmente gosto muito (e que palestrei bastante a respeito no começo do ano), que é sobre maestria. Em particular ele usou o tema do livro “Outliers” do Malcolm Gladwell, para explicar que talento é muito menos importante do que prática. Gladwell explica que, empiricamente, uma pessoa precisa de pelo menos 10 mil horas de prática antes de chegar ao estágio de mestre. Isso são 10 anos de esforço. Isso vai contra o “bom senso” de que “basta se formar” ou “basta se certificar” ou “basta ter um cargo de sênior” para se considerar bom em qualquer coisa. Novamente, um tema bastante comum atualmente para nós.

Para falar especificamente de Rails 3, eu pedi ao Matt Aimonetti, um dos Rails Activists e ao José Valim, que participou do Google Summer of Code. O Ilya Grigorik e o Marcos Tapajós falaram de duas temas mais modernos, PubSubHubBub e CouchDB. As palestras um pouco mais técnicas ficaram a cargo do Leonardo Borges com JRuby, Arthur Zapparoli com Git, Glenn Vanderburg com Testes Fuzz, David Chelimsky com RSpec e Cucumber, o Carlos Brando falou sobre criar um framework web com Ruby, o Gregg Pollack e o Pratik Naik nos mostraram diversas bibliotecas e técnicas que muitos desconheciam, e o Fabio Kung mostrou todo o poder da magia negra da metaprogramação Ruby, codificando uma DSL ao vivo!

Especificamente sobre Ruby, tivemos Rich Kilmer dando uma introdução ao Macruby e o Nando Vieira mostrando as novidades do Ruby 1.9. O Bruno Miranda falou sobre o case Cyloop, mais um exemplo de quão longe o Rails pode escalar. O Carlos Villela nos contou sobre a experiência da Thoughtworks em projetos de Ruby e, finalmente, o grande Vinícius Teles deu um show com um tema à la Getting Real da 37signals, falando sobre sua própria experiência como empreendedor e dando dicas valiosas para quem quer começar seu próprio negócio. De longe uma das palestras mais aplaudidas do Summit.

No primeiro dia ainda tivemos a famosa Desconferência, com várias boas palestras curtas. O pessoal do Guru-SP e RubyInside se apresentou. O pessoal da Plataforma Tec mostrou um plugin novo de autenticação, o Devise. O Cipriani deu um show técnico mostrando sistemas de comunicação em real-time usando Rails, AMPQ, etc. A galera do Rio, que veio em peso, falou de todas as atividades cariocas como o Dojo, o #horaextra, o Dev in Rio. O pessoal de Natal falou sobre eventos e do Oxente Rails 2010. Mas um dos pontos altos foi o Aldo Filho, irmão do Elomar, que fez uma palestra codificando ao vivo, com apenas 11 anos, demonstrando muito controle no que estava fazendo e falando tão bem quanto um profissional do palco. Dêem uma olhada:

Eu fiquei particularmente contente com a diversidade de assuntos e mais: como os brasileiros estão envolvidos em assuntos avançados. Espero que todos sigam os exemplos deles. Aliás, antes que eu me esqueça, dia 13, o primeiro dia do evento foi aniversário do José Valim e eu esqueci de dar os parabéns a ele! Sorry!!

Minha Palestra

Propositalmente, com tantos excelentes Railers e Rubistas presentes dando excelentes palestras, eu me dei ao luxo de palestrar sobre algo fora de Rails. Foi a segunda versão do tema “Além do Caos”. É uma palestra sobre agilidade que não fala especificamente sobre o que a maioria pensa sobre uma apresentação sobre metodologias Ágeis. Portanto nada de ficar pregando “farás TDD”, ou “farás pair-programming” ou qualquer outro tipo de dogmatização dessa maneira.

Partindo da premissa que, sim, metodologias ágeis funcionam “para quem pratica da forma correta” eu quero encontrar as razões de porque as coisas funcionam. O “porque” sempre é mais importante do que o “como”, porque o segundo é consequência do primeiro. Sem entender os fundamentos, jamais saberemos quando estamos indo na direção correta, jamais saberemos como decidir quando encontramos bifurcações. Em vez de ficar apenas com as anedotas, o “para ele funcionou então para mim deve funcionar”, o folclore, eu preciso entender os princípios.

Porém, mesmo depois de mais de um ano pesquisando a respeito em áreas como física, psicologia, sociologia, biologia, etc eu ainda não tenho um modelo unificado que explica todos os aspectos. Por isso o subtítulo da palestra é “Pensamentos Aleatórios sobre Agilidade”.

Alguns recados importantes que eu queria passar: 1) nós estamos acostumados demais a apenas dogmatizar e apresentar as coisas como “tudo funciona, basta fazer direito”, isso pode ser bom num curto primeiro momento, mas não se sustenta; 2) sim, agilidade funciona mas se mantê-la estática ela deixará de funcionar rapidamente, por isso é preciso entender os princípios para adaptá-la e evoluir; 3) agilidade não é o fim da linha, é apenas mais um passo evolutivo, existem mais caminhos à frente que alguns já desbravaram; 4) ninguém tem uma resposta exata ainda, por isso apenas discutir o sexo dos anjos não nos levará a lugar algum.

Nós, da organização do Rails Summit, gravamos todas as palestras. Eu ainda não sei como ficou porque o terceiro que ficou responsável por isso ainda não terminou de editar tudo. Assim que estiver tudo certo, vou publicar no site oficial do evento. Enquanto isso, alguns participantes gravaram algumas palestras, então vocês já podem se adiantar e assistir a minha por exemplo:

Além do Caos – Pensamentos Aleatórios sobre Agilidade from Locaweb on Vimeo.

Comunidade

A melhor parte do evento, sempre, é a participação da comunidade, e vocês não decepcionaram. Muitos Railers, todo mundo reunido, trocando idéias, experiências, essa é a idéia do evento. Assistir as palestras é apenas uma pequena parte. E isso é bem claro no pós-evento. Tanto no primeiro quanto no segundo dia, uma quantidade enorme de pessoas continuaram reunidas, socializando. No primeiro dia demos Denial of Service no Bar Brahma do Aeroclube, no segundo dia foi a vez de um stack overflow no bar Vila Vintém.

Este deve ser o único evento de tecnologia que dá ressaca depois :-) Enquanto todos se recuperam, alguns já começaram a reportar como foi o evento. Então lá vão alguns dos links mais recentes.

Quem quiser ver as fotos do evento, vejam estes álbuns:

Quem quiser assistir vídeos do evento, aqui vai:

Agaelebe: Blip.tv
Vimeo
YouTube!

Finalmente, os blog posts:

Alexandre Gazzola: Primeiro Dia e Segundo Dia
André Faria Gomes
Leonardo Faria: Primeiro Dia, Segundo Dia e Ecossistema
Carlos Brando: slides
Nando Vieira: slides and summary of the event
Matt Aimonetti: slides
Pratik Naik: slides
InfoEther
José Valim e Plataforma Tec: slides
Cairo Noleto: TrendTi.me
Blue Soft: Manifesto 2.0
Área Criações
SharpShooting
Willian Molinari
Carlos Antônio
Madruga on Rails
Alexandre Gomes: blog da SEA
Herbert Fischer

Espero que todos tenham aproveitado o evento. Não deixem de blogar, publicar suas fotos e vídeos, compartilhar o que aprenderam, novas inspirações, novas idéias. Obrigado a todos que participaram, espero revê-los até o ano que vem!

[Rails Summit 2009] ThoughtWorks pousa no Brasil

Thu, 08 Oct 2009 14:55:34 PDT

English readers: click here

Como eu twitei ontem, estamos muito orgulhos de anunciar que a ThoughtWorks se juntou como patrocinador da conferência na última hora. Inclusive eles resolveram dar um presente à comunidade: patrocinar metade de 30 ingressos para o Rails Summit, promoção que começou algumas horas atrás e ficará no ar até acabarem os ingressos patrocinados. Não percam!

Mais ainda, você deve ter ouvido rumores sobre isso. Roy Singham, fundador da ThoughtWorks, soltou o anúncio na conferência Agiles 2009 acontecendo em Florianópolis, SC alguns minutos atrás. Estou muito contente de confirmar que sim, os rumores eram verdade: a ThoughtWorks decidiu aterrissar no Brasil. Eles estabelecerão seu quartel-general em Porto Alegre, RS, começando este ano.

Agora, eles tem intenções de começar a contratar desenvolvedores de software brilhantes imediatamente. Eles estarão no Rails Summit para falar com você, procurando grandes pessoas para embarcarem nessa empreitada.

A ThoughtWorks é muito conhecida como uma força no mundo de desenvolvimento de software, com diversos escritórios pelo mundo. Eles tem grandes e conhecidos engenheiros, arquitetos trabalhando lá, redefinindo a maneira como fazemos software, como Martin Fowler.

Não percam essa oportunidade de vir conhecê-los, pessoalmente. Estaremos esperando por você no Rails Summit 2009, semana que vem!

ThoughtWorks lands in Brazil

As I twitted yesterday, we are very proud to announce that ThoughtWorks joined us as sponsor for the conference at the last moment.

Moreover, you may have heard rumors about this. Roy Singham, founder of ThoughtWorks, just released the announcement at the Agiles 2009 conference in Florianópolis, SC a few minutes ago. I am very happy to confirm that yes, the rumors are true: ThoughtWorks decided to land in Brazil. They will establish their head-quarters in Porto Alegre – RS, starting this year.

Now, they have intentions to start hiring bright and insightful software developers right away. They will be at Rails Summit to talk to you, searching for matches to sign up for their enterprise.

ThoughtWorks is a well known software development powerhouse, with offices around the globe. There are several great and well known engineers, architects working there, redefining the way we do software, such as Martin Fowler.

Don’t miss this opportunity to come and get to know them, in person. We will be awaiting you at Rails Summit 2009, next week!

[Rails Summit 2009] Palestrante Arthur Zapparoli

Tue, 06 Oct 2009 08:03:42 PDT

English translation: click here

Arthur é Desenvolvedor de Softwares, trabalha com Ruby e Rails desde 2006. Atualmente trabalha para a startup brasileira Spix. É conhecido como @ArthurGeek na comunidade e publica artigos no seu blog no qual fala sobre assuntos relacionados à desenvolvimento.

Ele foi um dos que começou a evangelizar mais o Merb na comunidade brasileira, assim como o Git como versionador de controle.

AkitaOnRails: Como você encontrou Ruby/Rails, o que foi que mais te atraiu?

Conheci Rails na época da versão 0.13. Eu já trabalhava com Python, e adorava os recursos de uma linguagem dinâmica. Quando conheci o Rails, não me apaixonei por ele de cara, ainda gostava mais do Python. Nessa época, me envolvi com alguns “clones” do Rails para o Python (ironicamente, nenhum deles deu certo). Porém, como precisava de algo pronto para ser usado, acabei usando o Rails nos projetos da empresa onde trabalhava, e, com isso, precisei estudar Ruby da maneira certa. Depois disso, me apaixonei por Ruby e estou nessa até hoje. Claro que não abandonei o Python, mas hoje posso dizer que Ruby é minha linguagem favorita.

AkitaOnRails: Quais assuntos mais te interessam atualmente e porque?

Tenho um grande interesse pelo Rails 3, já que sempre gostei do Merb. Ruby 1.9 é algo que utilizo nos dias de hoje e estou sempre de olho nas novidades com relação à isto. Fora do mundo Ruby/Rails, me interesso bastante pelos “Document based databases” como CouchDB, e, principalmente o MongoDB. Tanto o Ruby 1.9 quanto o MongoDB é algo que utilizamos no dia-a-dia da empresa onde trabalho.

AkitaOnRails: Sobre o que trata a sua palestra e para que tipos de desenvolvedores é mais indicado?

A palestra se chama: “Git: Controle de versões do jeito certo” e abordará temas básicos, diferentes workflows e algumas dicas mais avançadas. É indicada para desenvolvedores que não usam nenhum controle de versões ou para aqueles que querem saber mais sobre como o Git pode ajudar no dia-a-dia de seu trabalho.

Speaker Arthur Zapparoli

Arthur is a Software Developer, works with Ruby and Rails since 2006. He currently works for a Brazilian startup Spix. He is known as @ArthurGeek in the community and posts articles in his blog, talking about topics related to software development.

He also began helping to evangelize more Merb in the Brazilian community as well as the Git version control system.

AkitaOnRails: How did you find Ruby / Rails, what attracted you the most?

I got to know Rails at the time of version 0.13. I’ve worked with Python, and loved the features of a dynamic language. When I met Rails, I didn’t fall in love with it right away, I still liked Python more. At that time, I got involved with some “clones” of Rails for Python (ironically, none of them worked for me). However, as I needed something ready to be used, I ended up using Rails in projects for the company where I worked, and, therefore, I had to study Ruby the right way. After that, I fell in love with Ruby and I’m with it today. Of course not I’ve not abandoned Python, but today I can say that Ruby is my favorite language.

AkitaOnRails: What topics interest you the most today and why?

I have great interest in Rails 3, as I always liked Merb. Ruby 1.9 is something that I use today and I’m always on the lookout for news regarding this. Outside the Ruby / Rails world, I’m very interested by “Document based databases” such as CouchDB, and especially MongoDB. Both Ruby 1.9 and MongoDB are things we use in a daily basis at the company where I work.

AkitaOnRails: What is your talk about and what kind of developers will benefit the most?

The talk is called “Git: Version control the correct way” and will address key topics, different workflows and some more advanced tips. It is recommended for developers who do not use any version control or for those who want to learn more about how Git can help in your daily workflow.

[Off-Topic] Windows and Unix: Promiscuidade

Sun, 04 Oct 2009 16:33:22 PDT

Desde que o Windows NT 3.1 foi lançado em 1993, ele sempre teve algum suporte a sub-sistemas. Os bons engenheiros contratados da DEC, que efetivamente desenvolveram o NT, levaram à Redmond tecnologias e conceitos desconhecidos a eles como portabilidade (na época ele rodava em processadores PowerPC, MIPS, etc), access control lists, microkernel, multi-tarefa preemptiva, etc. O NT suportava, além do sub-sistema Win32, também OS/2 e um ambiente mínimo POSIX.1.

De qualquer forma, esse suporte era bem rudimentar. Ele foi substituído anos depois pelo Services for Unix 1.0 em 1999 no NT 4.0 SP3+. Mas foi só no SFU 3.5, lançado em 2004, que esse suporte finalmente amadureceu a ponto de ser minimamente usável. Eu me lembro de usar o SFU 3.5 no meu desktop em vez do Cygwin (embora o Cygwin ainda pareça ter mais aplicativos e mais flexibilidade), mas pelo menos era um suporte “oficial” da Microsoft – se isso significa alguma coisa.

Junto ao SFU temos o suporte opcional da Interix, que completa esse suporte com um ambiente GNU mais completo, incluindo SDKs para recompilar ferramentas Unix para Windows com SFU. Com ele conseguimos finalmente ter ferramentas úteis no mundo Windows, como acesso ao OpenSSH.

Para os puristas, que não gostam de instalar nada que não seja “default” da Microsoft, saibam que no próprio Add and Remove Programs (no Windows 2003) como no Add Feature (no Windows 2008) você tem a opção Subsystem for UNIX-based Applications, também conhecido agora como SUA. Primeiro você precisa instalar esse sub-sistema.

Feito isso, você precisa baixar o Utilities and SDK para o Windows XP/2003 ou Windows Vista/2008, eles pesam uns 190Mb e 490Mb, respectivamente. A instalação deles é demorada, e a única coisa a se lembrar é:

Escolha a opção “Custom Installation” e não “Stantard”. Daí escolha todos os “opcionais” desmarcados, você precisará deles.
Quando aparecer opções como setuid, sutoroot, case-insensitive, também marque todas as opções.

Terminada a instalação, no caso do Windows 2008, você pode diretamente já baixar um dos bundles que já vem com todas as ferramentas que você precisa. Selecione o link correto para W2K8 e já baixe de uma vez o “Complete Toolset” para facilitar.

No Windows 2003, por alguma razão estranha – não sei se é somente na minha máquina – a instalação do bundle não funcionou. Em vez disso precisei baixar e instalar o Bootstrap Installer 3.5. No Windows 2008, se não quiser o bundle e quiser escolher os pacotes manualmente, nessa mesma página, baixe o Bootstrap Installer 6.0. Em todo caso esse é o mínimo para ter um Package Manager. Ele te dará condições de instalar pacotes mais ou menos como num Ubuntu você consegue fazer “apt-get install apache2”.

Ele provavelmente pedirá que você reboote a máquina, pelo menos no caso do Windows 2003. Depois, as duas primeiras coisas que eu instalei foram:

12	pkg_update -L bashpkg_update -L openssh

Pode parecer estranho o comando se chamar “pkg_update” mas existe um “pkg_add” que parece que é antigo e eles recomendam o primeiro. Outro detalhe: eu executei esses comandos via o “C Shell” que tem link no Start Menu. No Windows 2008, depois de instalar o Bash eu ganho um novo atalho, mas no Windows 2003 deu algum problemas e eu criei o atalho manualmente copiando a partir do “C Shell” e editando o caminho para executar “/usr/local/bin/bash -l”.

Para iniciar o daemon do OpenSSH basta fazer:

1	/etc/init.d/sshd start

Pelo visto o SUA reinicia automaticamente os daemons configurados no /etc/init.d, como deveria mesmo. Isso lhe dá outras coisas como um daemon de cron, sendmail, dentre outros. Para acessar o sshd, não se esqueça de liberar incoming connections na porta 22 no Firewall do Windows (que vem ativado por padrão no 2008 e desligado no 2003).

Se você cair em algum problema de core dumps, segmentation faults, talvez você precise desligar o DEP. Para isso edite o arquivo C:\boot.ini e troque a opção “/NoExecute=…” por “/NoExecute=AlwaysOff”. Isso deve resolver esses problemas.

Finalmente, você precisa configurar uma variável de ambiente chamada “HOME” apontando para seu diretório padrão. No Windows 2003 foi “C:\DOCUME~1\ADMINI~1” e no 2008 foi “C:\Users\Administrator”. Feito isso, a partir do meu Mac, conectei nos Windows via SSH normalmente. Ele me pediu senha e me jogou no meu diretório com shell Bash. Até parecia que eu havia conectado num Unix normal.

Para ficar mais padrão, eu criei symbolic links para a pasta ‘home’:

1234	# Windows 2003:ln -s /dev/fs/C/Documents\ and\ Settings /home# Windows 2008:ln -s /dev/fs/C/Users /home

Então, eu criei um projeto Rails básico, sem nada. Rodei o meu Locarails para gerar uma receita básica de capistrano. Editei o “config/environment.rb” criado e comentei as linhas 74 e 88:

12	#run "cd #{release_path} && rake db:migrate RAILS_ENV=production"#run "ln -s #{deploy_to}/current/public #{public_html}/#{application}"

Lembrando que as configurações são case-sensitive e, no meu caso, estava testando com usuário “Administrator” (com “A” maiúsculo):

1	set :user, "Administrator"

Fiz um “cap deploy:setup”, depois um “cap deploy” e, voilá funcionou! Ele foi capaz de se conectar via SSH e realizar operações básicas como mkdir, ln, test e inclusive foi capaz de fazer upload dos arquivos via SCP.

Esse sub-sistema deveria vir instalado por padrão nos Windows, isso os tornaria mais úteis e incentivaria existir mais serviços como Capistrano que conseguem se comunicar com sistemas POSIX. No Windows tirando shares de rede (inseguro), RDP (inseguro), RPC (inseguro), FTP (inconveniente e inseguro) não sobra muita coisa para integrar. Com OpenSSH ganhamos um canal seguro, com autenticação simplificada graças ao sistema de troca de chaves e um ambiente POSIX onde podemos executar scripts e comandos para administrar as máquinas remotamente.

Vou fazer mais brincadeiras com esse ambiente, talvez coisas como Puppet, Chef, AutomateIt consigam fazer tarefas básicas em servidores Windows também. Outro detalhe: a conexão SSH só lhe dá acesso ao Bash ou outro shell Unix, mas não ao Command Prompt ou Powershell do Windows. Para isso você precisa de um servidor SSH comercial.

“Click e click Não é administração de sistemas. Um bom sysadmin tem intimidade com o console/shell.”

[Rails Summit 2009] Palestrante Nando Vieira

Thu, 01 Oct 2009 08:32:35 PDT

English translation: click here

Nando Vieira é um dos rubistas mais antigos da nossa comunidade. Ele bloga no Simples Ideias, um dos blogs mais conhecidos sobre Ruby on Rails do Brasil. Trabalha atualmente como desenvolvedor web na Abril Digital, utilizando Rails. É também o fundador do Spesa, além de manter dezenas de projetos Open-source.

Recentemente lançou um e-Book da sua série HOWTO entitulado O que mudou no Ruby 1.9. Da mesma série você pode baixar o e-Book gratuito Rails Application Templates que ele também escreveu.

Venha conhecê-lo no Rails Summit Latin America, que acontece nos dias 13 e 14 de Outubro. Estamos chegando perto. Você já se inscreveu?

AkitaOnRails: Como você encontrou Ruby/Rails, o que foi que mais o atraiu?

Conheci o Rails ainda na versão 0.13. Na época, não tinha quase nenhum blog em português sobre o tema e decidi criar o meu! Tinha visto algum artigo falando sobre ele e sobre como era fácil criar aplicativos e fui conferir. Por coincidência, estava querendo conhecer uma nova linguagem e quando vi a sintaxe do Ruby, decidi que era ela que eu iria aprender! E nessa estou até hoje!

AkitaOnRails: O que você tem estudado ou desenvolvido recentemente, seja em projetos particulares ou open source?

Tenho visto bastante coisa sobre o Ruby 1.9, principalmente para poder adequar meus projetos a esta versão. Além disso, tenho me interessado bastante sobre testes em geral, principalmente Javascript (JSpec e Screw Unit) e Aceitação (Cucumber).

AkitaOnRails: Sobre o que trata a sua palestra e para quais tipos de desenvolvedores é mais indicado?

Irei abordar as mudanças do Ruby 1.9 em relação à versão 1.8, com exemplos mostrando as novas funcionalidades e como corrigir comportamentos que deixaram de funcionar. É um assunto indicado para todos os programadores, pois cedo ou tarde, esta será a versão recomendada!

Speaker Nando Vieira

Nando Vieira is one of the luminaries of the Brazilian Ruby Community. He blogs at Simples Idéias, one of the most popular blogs about Ruby on Rails in Brazil. He currently works as web developer for April Digital, using Rails. He’s also the founder of Spesa, and maintains dozens of Open-source projects.

He recently released an e-book of his HOWTO series titled What has changed in Ruby 1.9. In the same series you can download the free e-Book Rails Application Templates which he also wrote.

Come meet him at Rails Summit Latin America, on October 13th and 14th. We’re getting close. Have you registered already?

AkitaOnRails: How did you find Ruby/Rails, what attracted you the most?

I found Rails when it was still in version 0.13. At the time, there was nearly zero blogs in Portuguese about the subject and I decided to create my own! I had seen an article talking about how easy it was to create applications with it and I decided to give it a shot. Coincidentally, I was thinking of learning a new language and when I saw the syntax of Ruby, it was decided that I would learn it! And I continued up to this day.

AkitaOnRails: What have you studied or developed recently, for private projects or open source?

I’ve seen quite a lot about Ruby 1.9, mainly in order to tailor my projects to this version. Also, I have been concerned enough about testing in general, especially Javascript (JSpec and Screw Unit) and Acceptance Testing (Cucumber).

AkitaOnRails: What is your talk about and what kinds of developers are going to benefit the most?

I will address the changes in Ruby 1.9 from version 1.8, with examples showcasing the new features and how to fix the behaviors that no longer work. It is a subject recommended for all developers, because sooner or later, this will become the mainstream version!

[Rails Summit 2009] Palestrante Ilya Grigorik

Sun, 27 Sep 2009 19:18:40 PDT

English translation: click here

Ilya Grigorik é um desenvolvedor Ruby bem conhecido, especialmente por causa do seu blog Igvita.com onde encontramos alguns dos artigos tecnicamente mais ricos e ainda assim de fácil compreensão, não só em torno de aplicações Rails, mas tudo que se relaciona com ele, incluindo drivers de banco de dados, análise de desempenho, integração de serviços e muito mais. Por causa disso ele foi premiado como Ruby Hero na RailsConf 2008 em Portland.

Ele também é o fundador do PostRank, um sistema de monitoramento em tempo real de engajamento social de mídia e plataforma de análise. Ele acabou de lançar um outro produto complementar chamado Analytics, outra ótima maneira de controlar os seus relacionamentos.

Você terá uma grande oportunidade de conhecê-lo no Rails Summit Latin America este ano. Não esqueça de se inscrever logo! Estamos apenas a mais alguns dias de distância!

AkitaOnRails: O que você mais gosta sobre a linguagem Ruby, o recurso ou conceito que “clica” para você?

Eu não consigo escolher apenas um atributo, pois como a maioria das coisas, geralmente é a soma das partes que compõe a experiência. E, na verdade, é o que eu mais gosto sobre Ruby: todas as peças “clicam” juntas. As decisões de design por trás da linguagem Ruby dão uma natureza incrivelmente maleável: é fácil estendê-lo, é fácil modificá-lo, é fácil fazê-lo funcionar da maneira que você precisa para trabalhar na sua aplicação. Rails é o principal exemplo disso, mas as centenas de outras estruturas construídas em cima de Ruby são todos exemplos dessa propriedade.

AkitaOnRails: Como um desenvolvedor Rails, o que é a coisa que você realmente gosta quando está codificando aplicações web?

A capacidade de ir do nada para um protótipo totalmente operacional, em uma xícara de café. Se você está olhando para uma aplicação Rails, ou uma rápida em Sinatra / Rails Metal, a enorme quantidade de recursos e plugins torna o processo divertido e imediatamente gratificante.

AkitaOnRails: Qual é a sua mais recente pesquisa ou interesse em desenvolvimento?

Muito do meu tempo é dedicado à investigação e criação de protótipos de instrumentos e abordagens de arquiteturas de software distribuído – desde mensagens, para balanceamento de carga, a bancos de dados. Combinado com o fato de que a maioria dos serviços que implantamos no PostRank são escritos em Ruby, significa também se aprofundar mais na compreensão das partes internas do Ruby, tentando otimizar a VM para uma arquitetura distribuída.

AkitaOnRails: Sobre o que é a sua palestra para o Rails Summit e quem são os tipos de desenvolvedores que se beneficiarão mais?

Nesta palestra vou cobrir as tecnologias emergentes por trás da “Real-Time Web” (XMPP, AMQP, PSHB, Webhooks). A adoção do Rails ao modelo RESTful liberou os dados dos aplicativos e nos permitiu definir serviços que poderiam facilmente falar uns com os outros, a Real-Time Web está indo um passo além: em vez de diferentes web-services se consultando o tempo todo, conectá-los através de interfaces push. Esta palestra terá início a partir do início e fornecerá uma visão geral de alto nível das tecnologias subjacentes. Saindo dela, você deve ser capaz de diferenciar e decidir sobre qual tecnologia se adaptará melhor às suas necessidades (não são todos iguais!).

Speaker Ilya Grigorik

Ilya Grigorik is a very well known Ruby developer, specially from his blog Igvita.com where one can find some of the most technically rich yet easily understandable articles surrounding not only Rails apps but everything that goes with it, including database drivers, performance analysis, services integration and much more. Because of that he was awarded Ruby Hero at RailsConf 2008 in Portland.

He is also the founder of PostRank, a real-time social media engagement monitoring and analytics platform. He just released another companion product called Analytics, another great way to keep track of your online engagements.

You will have a great opportunity to get to know him at Rails Summit Latin America this year. Don’t forget to Register! We’re just a few more days away!

AkitaOnRails: What do you like the most about the Ruby language, what feature or concept really “clicks” for you?

I can never pick any one attribute because as with most things, it is usually the sum of parts that makes up the experience. And in fact, that’s what I enjoy most about Ruby: all the parts click together. The design decisions behind the language give Ruby an incredibly malleable nature: it is easy to extend it, it is easy to modify it, it is easy to make it work in just the way you need it to work for your application. Rails is the premier example of this, but the hundreds of other frameworks built on top of Ruby are all examples of this property.

AkitaOnRails: As a Rails developer, what is the thing you really enjoy when you’re coding web apps?

The ability to go from nothing to a fully operational prototype with one cup of coffee. Whether you’re looking at a fully fledged Rails application, or a quick Sinatra / Rails Metal app, the sheer amount of resources, and plugins makes the process both fun and immediately rewarding.

AkitaOnRails: What are your most recent research or development interests?

A lot of my time is always dedicated to research and prototyping of tools and approaches for distributed software architectures – anything from messaging, to load balancing, to databases. Combined with the fact that most of the services we deploy at PostRank are written in Ruby, it also means delving deeper into understanding the internals of Ruby, and trying to optimize the VM for the distributed architecture.

AkitaOnRails: What is your Rails Summit talk about and who are the kind of developers that will benefit the most?

In this talk I will cover the emerging technologies behind the ’Real-Time Web" (XMPP, AMQP, PSHB, Webhooks). Rails adoption of the RESTful model liberated the data from the app and allowed us to define services that could easily talk to each other, the Real-Time Web is looking to go one step beyond that: instead of polling different web-services, it aims to connect them via push interfaces. This talk will start from the beginning and will provide a high-level overview of the underlying technologies. Coming out of it, you should be able to differentiate and decide on which technology suits your needs best (they are not all the same!).

[Off-Topic] Procurar Raciocionar Faz Bem

Sat, 26 Sep 2009 18:17:54 PDT

Esta semana surgiram alguns artigos interessantes, todos relacionados de alguma forma ao pensamento “Agile” de desenvolvimento de software.

O primeiro, que eu achei muito bom, foi o 10 razões porque Pair Programming não é para as massas que o Obie Fernandez escreveu a respeito de sua própria experiência com programação pareada e porque ela é difícil de ser implementada na maioria dos lugares.

Esses pontos se resumem em limitações físicas (cubículos são tão século XX …), convencionalismos corporativos ainda em voga (entrevistas feitas por RH baseado em currículo, primando por certificação, por exemplo). Para mim, dois dos pontos mais importantes são o 6o. e o 2o. Como qualquer conceito, interpretado da forma errada, dará resultados errados.

A primeira coisa que um programador precisa entender sobre programação pareada é que existem sempre piloto e co-piloto. Há a imagem de que o piloto é o indivíduo produtivo naquele instante e o co-piloto apenas olha e acompanha, passivo, silencioso. De jeito nenhum: esta é a forma errada de se parear e é a forma que, corretamente, os não-programadores (gerentes, etc) imaginam estar pagando 2 pessoas mas tendo apenas o serviço de 1. Em programação pareada, ambos precisam obrigatoriamente estar participando. O co-piloto deve estar atento aos erros do piloto. O co-piloto deve estar pensando à frente, já imaginando alternativas melhores, eles devem estar ambos engajados em encontrar as melhores soluções. Mais do que isso: o teclado e o mouse devem conseguir trocar de mãos constantemente. Não existe pareamento onde o co-piloto fica o dia inteiro apenas observando. Se o co-piloto é passivo e silencioso, o piloto está pilotando sozinho, é como se ele estivesse sozinho, ponto.

Existem pelo menos dois tipos de pares: onde ambos são razoavelmente equivalentes em termos de capacidades ou onde um dos dois é menos experiente ou tem capacidades um pouco diferentes. No primeiro caso, a dinâmica deve ser mais óbvia, as idéias vão bater mais vezes, eles vão conseguir decidir coisas mais rapidamente. No segundo caso, um deles tem o objetivo de aprender rápido. Mais do que isso, o que sabe menos tem a obrigação de arriscar mais, sempre sob a supervisão do mais experiente. E jamais deve ser passivo, ele deve buscar conhecimento fora, quando não estão pareando, e nunca deve esperar que tudo o que ele vai aprender é o piloto quem tem a obrigação de ensinar. Isso é errado: quem sabe menos é quem sempre tem a obrigação de correr atrás, ou então assumir que não vai conseguir e abdicar da posição.

Lembrando que o valor fundamental da Agilidade se chama “Accountability”, não consigo traduzir isso ao pé-da-letra em português, mas seria algo além do que “responsável”. Uma equipe Ágil é uma equipe conscientemente “accountable” pelo que faz. Quando eles se decidem, junto com o cliente, o product owner, sobre o Sprint Backlog, por exemplo, eles não estão recebendo “ordens” do tipo “este sprint terá estas 10 user stories porque o chefe mandou.” Não, a equipe que se compromete com 10 stories está de fato se “comprometendo”, ou seja, ela tem consciência da sua velocidade, das suas capacidade e das suas fraquezas e toma uma decisão racional baseada nisso. Uma equipe que depois diz “não deu para entregar porque pediram demais,” está se esquivando da sua responsabilidade. Ela deveria ter dito, no começo, “não, só conseguiremos fazer 8 dessas user stories, 10 é demais.” Combinado não sai caro. É tudo uma questão de acertar expectativas e negociar, colaborar em buscar a melhor solução, não “qualquer” solução.

O mesmo vale no mundo reduzido entre 2 programadores pareando. Ambos precisam estar comprometidos com o que estão produzindo e com o colega. Se um deles é menos experiente, ele não deve ser o peso morto. Por outro lado, claro, se o mais experiente vê que o outro está tentando, ele deve ajudá-lo. Há um limite, claro, entre “ajudar” e “carregar nas costas”. Aqui vale a honestidade, e por isso existe uma fase no fim do Sprint chamado “Retrospectiva”, é exatamente o momento para se discutir isso e deixar tudo aberto, às claras. “Eu não gosto do fato de estar produzindo sozinho, enquanto meu par não está ajudando.”

Programação em Par, por si só, é apenas uma técnica. Mas lembrem-se que antes disso existem os valores do Manifesto Ágil. Todos sempre se esquecem: “Indivíduos e Interações mais do que Processos e Ferramentas.” Se você está ainda se perguntando “quais das técnicas Ágeis eu devo escolher usar”, você ainda não entendeu. Antes de mais nada: você está comprometido com seu projeto? Sua equipe está comprometida com o projeto e com seus pares? Quais são os problemas que você quer resolver? Agilidade, por si só, não é uma receita mágica. Ela tem propósitos, se você não está mirando nesses propósitos, mas apenas escolhendo aleatoriamente 2 ou 3 práticas, isso não o torna Ágil, isso apenas o torna aleatório.

Daí vem o artigo do Joel Spolsky, sobre O Programador Fita Adesiva. Nesse artigo ele celebra um programador chamado Jamie Zawinski, de fato um grande programador, que trabalhou na Netscape produzindo software que ajudou a mudar o mundo, literalmente. Zawinski, segundo Spolsky, é do tipo “vamos lançar software o mais rápido possível, não importa como.” e também do tipo “testes unitários são bonitos, mas quando o prazo aperta, o que importa é fazer rápido, e testes atrapalham.” Lido da maneira errada, ela se torna uma desculpa para maus programadores dizerem: “Viva! Estou confirmado! Joel Spolsky disse que é bonito ser um programador cowboy!” Pior ainda: “Joel Spolsky disse que eu não preciso me preocupar com testes.”

Antes de pular para alguma conclusão precipitada – maldita geração “fast-food” – leia a resposta a esse post escrita pelo bom e velho Uncle Bob Martin onde ele refuta esses argumentos. Na realidade Spolsky e Bob já andaram se “pegando” algumas vezes no passado quando num podcast o Spolsky menosprezou TDD e os princípios SOLID.

Robert Martin, que se você não conhece, foi quem originou a reunião de uns 10 anos atrás, junto com os principais pensadores em desenvolvimento de software como Kent Beck, Martin Fowler, Dave Thomas, Jeff Sutherland, dentre tantos outros, que deu origem ao Manifesto Ágil. Ele que é programador ativo desde antes ainda de qualquer um de nós ter nascido e que ainda programa até hoje. E não estou dizendo um sênior que ainda só programa em Cobol, muito pelo contrário, que já passou pelas principais plataformas tecnológicas, entende orientação a objetos como ninguém, programa em Java, e é um defensor de Código Limpo. Aliás, se você é usuário do Github, pode encontrar alguns projetos do Bob por lá também.

Algum tempo atrás, eu provavelmente estaria xingando e amaldiçoando o Spolsky, porém eu acho que entendo a posição dele. Dando o contexto, o Spolsky é de fato um grande empresário, tem uma empresa bem sucedida, com produtos de nicho bem sucedidos, não deixa de ser uma 37signals da geração anterior. Ex-funcionário da Microsoft, ele foi um dos responsáveis pela existência do Visual Basic for Applications, que até hoje é o coração do Excel e a menina-dos-olhos de qualquer contador, analista, etc que basicamente não vivem sem as macros do Excel. Junto com Jeff Atwood ele mantém o famoso site StackOverflow. Além disso tem o excelente livro Joel on Software.

Neste ponto eu estou assumindo que não preciso lhes explicar o que é Agilidade, nem quais são algumas das principais boas práticas de Extreme Programming, nem o que são os princípios SOLID do Bob Martin. Também estou assumindo que você já leu pelo menos alguns dos artigos do Spolsky para ter uma idéia do que ele costuma falar.

Normalmente um agilista parece que está numa posição de “convencer” os outros de porque ser ágil é melhor. Mais do que isso: de que ser “ágil” e ser “rápido” não são sinônimos. Ser rápido é um efeito colateral de ser ágil. Essas interpretações são sutis.

Por isso mesmo o que eu amaldiçôo é a geração fast-food: uma geração que se acostumou a pensar que as coisas são simples e superficiais. Que basta comprar um livro de “emagreça em 7 dias” para realmente emagrecer. Surpresa: se esse tipo de coisa realmente funcionasse, não haveria obesos no mundo. Duh.

Essa mesma geração lê o que o Spolsky fala e, superficialmente, chega às conclusões que falei acima: “o Spolsky concorda que eu devo ser cowboy.” E eu acho que muitos de nós, agilistas, somos vítimas disso também. Na ânsia de responder à essa superficialidade, acabamos até ultrapassando a linha. O Bob Martin, por exemplo, poderia simplesmente ter ignorado esse post em vez de ter respondido.

Pessoas passivas, conformistas, esperam ser validadas. Elas não entendem porque fazem o que fazem, apenas fazem. Claro, fazem o que lhes parece mais simples, mais fácil, mais seguro, e não o que tem chances de ser melhor, que pode trazer mais benefícios, ou que seja novo. Elas querem que as pessoas gostem delas. Não importa se estão fazendo as coisas certas ou não. Não importa se há maneira melhor. Por isso essa ânsia em validação. Foi sobre isso que traduzi no artigo Culto da Moral Cinzenta.

Quando alguém do “calibre” – pelo menos do “calibre” perceptível – de um Spolsky lança um post como esse, milhares de programadores nitidamente ruins ao redor do mundo se sentem validadas, justificadas. É um cenário triste.

E o Spolsky não está errado. O que ele coloca em cada um de seus artigos são pedaços de sua própria experiência. Cada pedaço, individualmente, não significa absolutamente nada. E não deve ser levado ao pé-da-letra. Aliás, nem mesmo o que o Bob Martin escreve num artigo. Nem mesmo o que eu escrevo num artigo. O resultado da soma das partes é ordens de grandeza maior do que a simples soma dos valores individuais de cada parte. É assim que funciona o caos.

Ambos, Spolsky e Bob, não são antagônicos. O que um diz não invalida o que o outro diz. Esse é o truque. Ambos são “pragmáticos”, pelo menos segundo a definição de Pragmatismo de William James, onde algo é verdade para uma pessoa se ela tem utilidade para ela, independente se essa verdade continua sendo verdade para outra pessoa. (claro, ainda existe a interpretação de pragmatismo de Peirce e Dewey, mas isso é outra história). Ambos tentam explicar o que fazem que funcionam para eles. Dentro de um contexto, dentro do entendimento das premissas, dentro do entendimento dos valores, isso pode talvez funcionar para você também.

O que quero dizer é que o que o Spolsky diz faz sentido para ele. O que Bob Martin diz faz sentido para ele. Se o que eles dizem fazem sentido para mim, ou para você, isso não é problema deles, não é culpa deles, não deveria ser sequer do interesse deles. Da mesma forma, não usem o nome deles para justificar o que você faz ou diz sem entender porque está dizendo isso. “Eu faço TDD porque o Kent Beck disse que é bom” é tão ruim de se dizer quanto “Eu faço código-grude porque o Zawinski disse que é melhor.”

Você deve dizer: “Eu faço TDD porque eu sei quais são os benefícios que isso trás para mim.” Ou, “Eu faço código-grude de vez em quando porque tenho consciência das consequências que isso vai me trazer e aceito pagar o preço por isso.” Ou, “Eu não faço programação em par o tempo todo porque eu já analisei e concluí que no meu caso isso não funciona muito bem.”

Aliás, tudo que eu digo aqui – no meu blog – são elocubrações, reflexões pessoais, que porventura encontram seu caminho na forma escrita. Alguns acham que eu “me acho o dono da verdade”. Pois bem, isso é um problema de quem acha isso, não meu.

Verdade seja dita: assim como o Bob diz no artigo dele, eu também não faço testes o tempo todo, muito menos testes primeiro como dita o TDD. Conheci as práticas de Extreme Programming apenas muitos anos depois que comecei como programador. Fui um programador extremamente cowboy a maior parte da minha carreira. E, mesmo entendendo porque todas as práticas ágeis são boas e porque eu deveria usá-las, eu ainda raciocino onde e quando devo usar o que. Quer dizer, eu entendo os princípios, as premissas e os resultados esperados. Caso contrário isso seria dogmatização e, por definição, tudo que é dogmatizado é ruim. Dogmas são a origem de todo o mal. Tudo deve ser questionado, experimentado, medido, analisado e só então alguma conclusão pode surgir e, mesmo assim, pode ser refutado no futuro por novas evidências. O oposto de Dogma ou mesmo Cargo Cult é o Método Científico como eu já expliquei anteriormente.

Só porque foi o Martin Fowler quem falou, não torna isso uma verdade incontestável. Só porque o Ward Cunningham falou não é verdade absoluta. Todos eles, todos nós, somos seres humanos e, como tal, somos muito falíveis. Nós falhamos, e falhamos muito mais do que gostaríamos.

Num mundo onde as pessoas falham, o que funciona melhor é o conhecimento coletivo, onde a possibilidade do erro de um é compensada pela inteligência complementar do outro. Por isso mesmo comunidades – apenas as que primam pelo conhecimento e evolução, claro – tendem a ser ordens de grandeza menos falíveis do que um único indivíduo.

Se um indivíduo tem o conhecimento “A”, se outro indivíduo tem o conhecimento “B”, nenhum dos dois tem o conhecimento “total”, mas o conjunto dos dois, a “comunidade”, tem ambos os conhecimentos. Sozinhos eles sabem apenas parte da informação. Porém a “entidade” chamada “comunidade” é o mais próximo que conseguiremos chegar de omnisciência.

Por acaso, compartilhar conhecimento com os outros nos trás benefícios, e é por isso que o fazemos, não porque somos puramente altruístas. Dar sem ter nada para receber não faz sentido, muitos dão simplesmente porque isso lhes trás “paz de espírito” ou “satisfação pessoal”. Muito bem, isso é um tipo de retorno, também funciona. Pessoas como Kent Beck, Martin Fowler, Ken Schwaber, não estão “dando” nada. Elas estão compartilhando, ao ajudar a fomentar os valores ágeis, eles recebem de volta, seja na forma de mais conhecimento, mais reconhecimento, mais oportunidades, etc. Isso nos leva à boa e velha evolução darwinista, a única coisa que efetivamente funciona para melhoria contínua.

O objetivo não é “vender” Ágil. Quando eu evangelizo a filosofia Ágil, não tenho nenhuma intenção de convencer ninguém a usar. Não ganho dividendos se mais pessoas usarem. Alguns até me cobram: “se eu usar Ágil, você me garante que vou ter resultados melhores?” E eu respondo, “claro que não, eu não garanto nada.” Eu compartilho o que funciona para mim, se isso vai funcionar para os outros realmente não é problema meu. O que eu espero, sim, é que quem esteja usando e descubra coisas novas, que compartilhe para que eu possa melhorar mais também. E, claro, se alguém me der um código mal feito, cheio de fita adesiva, sem nenhum teste, e espera que eu conviva com isso em silêncio, está redondamente enganado, porque isso não funciona para mim e eu não vou ficar quieto. Concordando com o Bob Martin, Bagunça não é Dívida Técnica, é apenas Bagunça

Algumas dicas: qualquer coisa que é “escrita em pedra”, ou seja, algo que um dia foi o resumo do conhecimento coletivo de um grupo, mas que foi imortalizado na forma de um dogma, é ruim. Porque isso, sem dúvida, foi útil para as pessoas da época em que foi escrito, mas possivelmente não vale mais hoje. Por exemplo, se ainda seguimos os dogmas de desenvolvimento de software de 50 anos atrás, possivelmente estamos deixando de fazer as coisas da forma que a tecnologia e o conhecimento atual permitem. Por outro lado, um corpo de conhecimento que se permite evoluir, refinar, jogar fora o que não funciona mais, adicionar o que se aprende de novo, tem muito mais chances de estar certo. A comunidade Ágil funciona mais ou menos assim. A comunidade Open Source funciona mais ou menos assim. Nenhuma delas é perfeita, mas é a busca pela perfeição que torna o caminho mais interessante.

Seja cético.

[Rails Summit 2009] Palestrante Matt Aimonetti

Wed, 23 Sep 2009 17:13:12 PDT

English translation: click here

Matt Aimonetti é um ativista Rails, ele começou como evangelista de Merb e se envolveu na já famosa junção do Rails + Merb. Ele também é ativo na área de MacRuby e HotCocoa. Ele mora em San Diego, onde dirige sua própria consultoria, fazendo projetos e treinamentos relacionados com Ruby, e ele também é um palestrante conhecido em eventos. Nós nos encontramos pela primeira vez no ano passado, na QCon de São Francisco. Você pode ouvir a entrevista que gravamos naquela época aqui

Ele estará conosco no Rails Summit Latin America 2009. Não esqueça de se inscrever!

AkitaOnRails: O que você mais gosta na linguagem Ruby, qual recurso ou conceito te atrai?

Acho que o Ruby é a melhor linguagem de programação para expressar o que eu quero no meu código. É tão natural que parece mesmo “certo”. As pessoas são, como o falecido Guy Decoux era, capaz de se comunicar apenas em código Ruby e isso significa muito para mim. Mas há mais do que a fantástica sintaxe. Ruby tem uma maravilhosa comunidade e valores fortes, tais como testes, refatoramento, melhores práticas, open source etc.

Eu estou realmente empolgado vendo empresas como a Apple e a Microsoft apostando fortemente na linguagem Ruby e sua comunidade.

AkitaOnRails: Qual é a coisa que você mais gosta sobre Rails quando codifica aplicações web?

O que eu mais gosto quando escrevo uma aplicação Rails está em usar Ruby. Eu tentei usar outros clones de Rails em outras línguas e nenhuma chegou perto da mesma experiência, devido à linguagem de programação subjacente. Mas além do Ruby, minha segunda coisa favorita sobre o Rails é a seqüência de uso de convenções inteligentes. Eu posso ver qualquer projeto Rails e compreender imediatamente o que está acontecendo.

AkitaOnRails: Qual é o seu interesse mais recente de pesquisa ou desenvolvimento?

Eu aprendi muito sobre Ruby, trabalhando em MacRuby. Como se vê, há um monte de coisas no Ruby e suas bibliotecas-padrão que muito raramente uso. Eu também estou experimentando com pequenos jogos 2D escrito em Ruby. É uma mudança agradável de desenvolvimento web. Finalmente, eu ainda estou trabalhando com CouchDB e armazenamento de dados alternativos.

AkitaOnRails: Sobre o que é sua palestra para o Rails Summit e quem são os tipos de desenvolvedores que irão se beneficiar mais?

Minha palestra é sobre o futuro do Ruby on Rails e concretamente o que isso significa para os desenvolvedores. Não será uma palestra sobre o encanamento interno, mas mais sobre uma perspectiva de alto nível com exemplos de nível mais elevado de código e exemplos concretos de coisas novas impressionantes que estarão disponíveis para os desenvolvedores Ruby.

As pessoas que estão interessadas no que está chegando, os céticos e pessoas considerando usar Ruby/Rails pela primeira vez provavelmente acharão isso interessante.

Além disso, se você gosta de “futebol”, deveria vir assistir minha palestra ;)

Speaker Matt Aimonetti

Matt Aimonetti is a Rails Activist, he started as a Merb evangelist and was involved in the now famous Rails + Merb merge. He is also active in the MacRuby arena with HotCocoa. He lives in San Diego where he runs his own consultancy, doing Ruby related projects and training, and he is also a well known speaker in events. We met for the first time at last year’s San Francisco QCon. You can listen to an interview we recorded back then here

He will be with us at Rails Summit Latin America 2009. Don’t forget to register soon and make reservations for hotel and city tour (it will be a great opportunity to also get to know São Paulo City).

AkitaOnRails: What do you like the most about the Ruby language, what feature or concept really “clicks” for you?

I found Ruby to be the best programming language to express what I want my code to do. It is so natural that it feels “right”. People are, like the late Guy Decoux was, able communicate only in Ruby code and that means a lot to me. But there is more to it than the awesome syntax. Ruby has an awesome community and strong values such as testing, refactoring, best practices, OSS etc..

I’m really psyched to see companies like Apple and Microsoft bet heavily on the Ruby language and community.

AkitaOnRails: What is the thing you really enjoy about Rails when you’re coding web apps?

What I enjoy the most when writing a Rails app is using Ruby. I tried using other Rails clones in other languages and none came close to the user experience due to the underlying programming language. But apart from Ruby, my second favorite thing about Rails is the string use of smart conventions. I can take almost any Rails projects and understand right away what’s going on.

AkitaOnRails: What are your most recent research or development interests?

I learned so much about Ruby by working on MacRuby. As it turns out, there are a lot of goodies in Ruby and its standard libraries that we very rarely use. I’m also experimenting with small 2D video games written in Ruby. It is a nice change from web development. Finally, I’m still working with CouchDB and alternative data storage.

AkitaOnRails: What is your Rails Summit talk about and who are the kind of developers that will benefit the most?

My talk is about the future of Ruby and Rails and what it concretely means for developers. It’s not going to be a talk about the inner plumbing but more about the big picture with higher level code examples and concrete examples of awesome new things that are going to be available to Ruby developers.

People who are interested in what’s coming up, skeptics and people considering using Ruby/Rails for the first time will hopefully find the talk interesting.

Also, if you like “futebol” you should definitely come check out my talk ;)

[Rails Summit 2009] Palestrante Carlos Brando

Mon, 21 Sep 2009 06:18:29 PDT

English translation: click here

O Carlos Brando acho que dispensa apresentações :-) Todos já o conhecem pelo blog Nome do Jogo, pelo e-book Rails 2.1 e por projetos open-source como o Remarkable. Dentre suas colaborações mais recentes, está a tradução do excelente livro do _why, o Poignant Guide to Ruby; e o lançamento da versão nacional do site britânico Ruby Inside

Na sua própria descrição, ele é viciado em programação e atualmente é diretor de tecnologia da Amanaiê, uma empresa que cria, produz e distribui aplicativos sociais. Atua na área de desenvolvimento de softwares há mais de doze anos, tendo trabalhado com Visual Basic, C, C++, Java, C# e agora Ruby. Já trabalhou em várias companhias brasileiras e estrangeiras como Portugal Telecom Group, AT&T Latin America, DirecTV, SKY, VISA e Surgeworks Inc.

Já se apresentou em vários eventos brasileiros relacionados com Ruby, incluindo a edição do ano passado do Rails Summit Latin America.

Além de suas atividades profissionais, Carlos e sua esposa trabalham como voluntários dando aulas para deficientes auditivos. Ele regularmente ensina língua de sinais e atua como interprete.

AkitaOnRails: Como você encontrou Ruby/Rails, o que foi que mais te atraiu?

Eu já trabalhava há 12 anos como programador e pelo menos 7 principalmente com tecnologia Microsoft e estava um pouco cansado de fazer as mesmas coisas todos os dias, literalmente tinha perdido o prazer no meu trabalho. Foi quando ouvi falar do Rails pela primeira vez, mas sem entender do que se tratava, simplesmente o ignorei. Alguns meses depois li um artigo no blog do Chad Fowler onde ele mencionava o Ruby e como estava feliz em trabalhar com esta linguagem e isto me fez voltar a olhar para o Rails.

Comecei estudando por conta própria e comprei o livro “Repensando a web com Rails” do Fábio Akita e o The Ruby Way de Hal Fulton. Em duas semanas eu já tinha montado meu primeiro site em Rails, o extinto CarreiraTI, um site de empregos para profissionais da área de tecnologia. Seis meses depois fui convidado para fazer parte da equipe da Surgeworks, onde trabalhei por quase 2 anos.

AkitaOnRails: Quais assuntos mais te interessam atualmente e por quê?

Tenho me interessado muito pelas entranhas da linguagem, entender como o Ruby funciona por dentro. Aos poucos estou deixando o Rails cada vez mais de lado, e me envolvendo mais com o Ruby.

AkitaOnRails: Sobre o que trata sua palestra e para que tipos de desenvolvedores é mais indicado?

Atualmente fui contratado por uma startup brasileira chamada Amanaiê, que desenvolve aplicativos para redes sociais. Depois de passar um tempo fazendo software para estas plataformas, estou trabalhando especificamente no desenvolvimento de um framework para acelerar a criação de projetos deste tipo. Durante muito tempo acompanhei de perto o desenvolvimento do Rails, o que me rendeu dois livros. Este conhecimento é o que tem me ajudado a repensar algumas coisas e criar um novo framework baseado no Ruby.

Minha palestra no Rails Summit tratará exatamente deste tema: o processo de construção de um framework utilizando Ruby. Se você realmente quer entender como o Rails funciona, então crie o seu próprio framework. Nesta palestra vou comentar sobre algumas das dificuldades que encontrei durante este projeto e quais as soluções encontradas. O processo de renderização, geradores de códigos, helpers e banco de dados estão entre os assuntos que serão tratados. Acredito que ao analisar este tópicos de um ponto de vista mais simplista fará com que você entenda melhor como algumas coisas funcionam internamente no Rails.

Speaker Carlos Brando

I think Carlos Brando needs no introduction :-) Everyone knows his blog Nome do Jogo, the e-book Rails 2.1, his open-source projects such as Remarkable. Among his most recent collaborations, there’s the translation of the excellent book from _why, the Poignant Guide to Ruby; and the launch of the Brazilian version of the British website Ruby Inside.

In his own words, he is addicted to programming and is currently chief technology officer for Amanaiê, a Brazilian company that creates, produces and distributes social applications. He is in the software development field for over twelve years, having worked with Visual Basic, C, C++, Java, C# and now Ruby. He has worked in several Brazilian and foreign companies like Portugal Telecom Group, AT&T Latin America, DirecTV, SKY, VISA and Surgeworks Inc.

He has performed in several events related to Ruby in Brazil, including last year’s edition of Rails Summit Latin America.

In addition to his professional activities, Carlos and his wife volunteer teaching to deaf people. He regularly teaches sign language and acts as interpreter.

AkitaOnRails: How did you find Ruby / Rails, what most attracted you?

I’ve been working 12 years as a programmer and at least 7 of them primarily with Microsoft technologies; and I was a bit tired of doing the same things over and over. I’ve literally lost the pleasure in my work. When I heard about Rails for the first time – without understanding what it was – I simply ignored it. A few months later I read an article in Chad Fowler’s blog where he mentioned how happy he was to work with Ruby, and this made me take a second look at Rails.

I started studying on my own and bought “Rethinking the web with Rails” book by Fabio Akita and The Ruby Way by Hal Fulton. In two weeks I had set up my first site in Rails, the now extinct CarreiraTI, a job site for professionals in technology. Six months later I was invited to join the Surgeworks team, where I worked for almost 2 years.

AkitaOnRails: What subjects interest you the most nowadays and why?

I’ve been very interested in the inner plumbings of the language, to understand how Ruby works from the inside. I am gradually leaving Rails aside, and getting more involved with Ruby.

AkitaOnRails: What is your talk at Rails Summit about, and what kind of developers will benefit the most?

I am currently hired by a Brazilian startup called Amanaiê, which develops social network applications. After spending time making software for these platforms, I’m working specifically on developing a framework to speed up the creation of such projects. For a long time I closely followed the development of Rails, which resulted in two books. This knowledge is what helped me to rethink some things and create a new framework based on Ruby.

My talk at Rails Summit will address exactly this issue: the process of building a framework using Ruby. If you really want to understand how Rails works, then create your own framework. In this talk I comment on some of the difficulties I found during this project and what were solutions I used. The process of rendering, code generators, helpers and database are among the subjects to be treated. I believe that in examining this topic from a more simplistic standpoint will make you better understand how things work internally in Rails.

Rails Summit will have Portuguese to English translator, so you can watch Carlos talk too! Register now!

[Off-Topic] Meu Backup Pessoal (Drobo/Time Capsule)

Sat, 19 Sep 2009 15:16:21 PDT

Eu não sou muito paranóico com backup mas tomo meus cuidados. Por exemplo, eu não tenho 100% de confiança em storages remoto, seja ele Gmail, Amazon S3, Dropbox ou qualquer coisa desse tipo. Esse tipo de serviço é uma ajuda extra, mas jamais deve ser o storage primário. Meus e-mails, calendários, contatos estão todos centralizados no Mobile Me, meu Gmail faz forward de tudo pro Mobile Me servindo basicamente como um bom filtro de spam.

Eu tenho uma cópia de tudo isso sincronizado no meu Macbook, e tudo no meu Macbook está guardado no Time Capsule de 1TB, via Time Machine. Portanto eu tenho pelo menos 3 cópias de todos os meus dados mais importantes.

Para outros dados menos voláteis como vídeos, programas, projetos antigos e coisas desse tipo eu tinha dois discos externos ligados, um de 400GB e outro de 500GB, via USB 2 no meu Mac Mini de casa. Eles faziam rsync entre si todos os dias às 4 da manhã. Eu deixo meu Mac Mini ligado o tempo todo, ele não consome muita energia, e é silencioso ao nível de parecer que está desligado, o que é muito importante. Ele próprio também faz backup de si no mesmo Time Capsule. Desta forma todos os meus dados tem pelo menos um backup.

Para o dia-a-dia carrego outro disco externo LaCie de 500GB. Todo dado importante nele tem uma cópia nos discos externos de casa, ele serve apenas para transporte. Porém, essa configuração ainda é muito ruim. Primeiro porque esses cases de disco externo tem cada um uma fonte de energia e um cabo USB. É muito cabo bagunçado. Segundo, eles não foram feitos para ficar ligados o tempo todo, não tem inteligência e consomem muita energia, são muito barulhentos, acumulam muito pó, enfim, são péssimos para esse propósito. O próprio rsync uma vez por dia não é adequado, pois eu fico com uma janela de 24 horas descoberto.

Redundância é extremamente importante. Eu já me vi pensando “que desperdício, tenho 2 discos que somam quase 1TB mas só posso usar 400GB.” Mas esse é o ‘seguro’ que se deve pagar. De nada adianta usar 1TB e depois um dos discos quebra e você perde metade dos seus dados. Por isso há pelo menos 2 coisas que se pode fazer: um mirror bem caseiro com rsync como eu fiz, ou montar um micro caseiro com RAID via software.

Há alguns anos uma empresa chamada Data Robotics apareceu em cena e lançou um dos produtos que está na minha lista de compra faz quase 3 anos: o Drobo. Ele é literalmente um robô.

Como diz a definição da Wikipedia:

Um robô é um agente artificial virtual ou mecânico. Na prática, é normalmente uma máquina eletro-mecânica que é guiada por um computador ou programação eletrônica e, portanto, é capaz de realizar tarefas sozinho.

É exatamente isso que ele faz. Ele é um “enclosure”, uma caixa-preta, onde você pode encaixar facilmente até 4 discos SATA. Ele inteligentemente sabe como gerenciá-los sem precisar se preocupar em configurar partições, volumes, etc. Basta encaixar os drives e ele faz todo o resto. Internamente, ele faz a configuração que for necessária para otimizar o uso do espaço, seja um mirror simples se houver apenas 2 drives até algo parecido com um RAID-5 quando se tem pelo menos 3 drives. Mas nada disso é visível, ele apenas “faz”.

Claro, existem opções muito mais “baratas” em termos de custo de material. Como já disse, qualquer PC velho com software no estilo do FreeNAS ou mesmo um Linux normal onde você configura RAID via software manualmente serviria. A chave aqui é não pensar só no “agora” e pensar no “daqui a pouco”. Os cenários que um storage desse tipo (seja feito em casa, um drive externo como o LaCie, um Windows Home Server ou coisa do tipo) é justamente rápida recuperação quando um dos drives falha, de preferência o mais próximo possível de downtime Zero e fácil expansão: quando eu comprar um drive maior, quero somente encaixá-lo e quero que o sistema se vire para fazer tudo funcionar.

Nenhuma das alternativas, montadas em casa ou comerciais, tem capacidade para garantir downtime zero e expansão flexível inteligente. Este é o diferencial do Drobo, que atualmente simplesmente não tem nenhum equivalente no mercado. Ele é literalmente à prova de BIOS, ou mais adequadamente “Zero Configuration”: você liga na tomada, liga o cabo Firewire 800 ou USB 2 no micro e pronto, ele faz o resto.

Assista este vídeo com a Cali Lewis, é tudo que você precisa saber sobre o funcionamento dele:

É apenas isso mesmo. Veja mais detalhes no site oficial dele. Sim, o preço dele é “salgado”, não sai por menos de USD 400, isso sem contar os drives. Se considerar com mais 2 drives de 1TB cada (ele precisa de pelo menos 2 drives, de qualquer tamanho), o conjunto não sai por menos de USD 600. E junte a isso, claro, a taxa do seu “importador”.

Disclaimer

Antes que alguém comece, não, não estou dizendo que soluções caseiras de RAID são ruins. Se o Drobo não existisse seria exatamente o que eu faria: compraria um micro com gabinete pequeno, um controlador RAID, instalaria um FreeNAS ou algo assim e pronto. Porém, dado que o Drobo existe esta é a solução que eu pessoalmente preferi.

O preço é bem mais caro, pelo menos 2 ou 3 vezes mais, sem sombra de dúvidas, mas a comodidade e segurança de longe compensam. Não é o tipo de coisa que você decide comprar num piscar de olhos. Eu esperei quase 3 anos antes de finalmente comprar.

Qualquer solução que: 1) possibilitar downtime zero de recuperação e; 2) expansão elástica com drives de diferentes capacidades, também com downtime zero; será uma alternativa tão boa quanto o Drobo.

Para começar, veja o tamanho dele comparado ao meu Mac Mini:

Minha experiência até aqui

Meu Drobo está em funcionamento a menos de 24 horas ainda. Mas até agora ele é exatamente o que eu esperava. A primeira coisa que fiz foi ligá-lo na tomada, instalar o Drobo Dashboard (que pode ser baixado do site). Na primeira vez ele pede para formatar os discos e gerar o volume. Depois disso ele já aparece no meu desktop como mais um volume montado.

Daí eu transferi todo meu conteúdo dos drives externos para ele. Fiz isso via rsync mesmo (caso a transferência parasse no meio). Foram quase 400GB de conteúdo que levou mais de 10 horas durante a noite transferindo (USB 2 não é exatamente a coisa mais rápida do mundo).

Isso pronto, pela manhã eu já pude retirar os drives externos. Só isso já me deu um enorme alívio: foram toneladas de cabos a menos embaixo da minha mesa, cabos USB em cima e aqueles cases feios e empoeirados. Minha mulher agradece. Veja como o case estava acumulando muita poeira:

Retirei os drives dos cases, limpei e imediatamente inseri nos dois slots sobrando do Drobo. Ele imediatamente reconheceu os novos drives e, sem precisar desmontar o volume ou parar de copiar arquivos para ele, o espaço disponível aumentou dinamicamente. Essa é a facilidade inegável dessa arquitetura: agora tenho 2 drives de 1TB cada, um de 500GB e outro de 400GB formando um espaço útil de quase 1.7TB redundantes.

Claro, a brincadeira não estaria terminada se eu não pudesse testar a maior funcionalidade dele: retirar e recolocar drives dinamicamente sem perder acesso do micro ao volume. Foi o que eu fiz: retirei um dos discos, enquanto tudo estava ligado, para simular um drive com falha. Meu Mac Mini nem pestanejou e para ele o volume continuava ali, intacto, e eu conseguia acessar os dados sem problemas. Recoloquei o drive e após alguns segundos todas as luzes já estavam verdes novamente.

Veja a quantidade irritante de cabos que tinha no chão embaixo da mesa:

A principal vantagem se chama paz de espírito: eu sei que na hora de um aperto, quando um dos drives falhar (e um deles vai, eles sempre falham) será tão simples quanto comprar um novo drive e espetar no lugar. Ainda tem tempo para encher esses 1.7TB, mas se encher, basta comprar um drive maior e espetar no lugar do drive mais velho. E assim por diante.

Em termos visuais, o fato de ter tirado aquele monte de coisas atrapalhando da mesa e colocado um monolito elegante e simples é uma grande ajuda. Ele é um produto que foi feito com cuidado: nada de parafusos aparecendo, ventoinhas barulhentas. É um monolito negro, e com ótimo acabamento. Inclusive a tampa da frente, que dá acesso aos drives, é anexado magneticamente, também dispensando a necessidade de uma chave de fenda. São detalhes desse tipo que demonstram o cuidado que um fabricante tem com seu produto.

Agora, veja como minha mesa ficou muito mais agradável:

Tem tudo que um bom produto precisa: é efetivamente funcional, extremamente simples de usar, transmite segurança, e tem um excelente acabamento, é bonito. O software também é simples, tem o suficiente para informar e operar tudo que preciso – e na grande maioria do tempo ele vai ficar desligado – além disso o hardware em si é eficiente em mostrar as informações mais importantes como o estado dos drives (luzes verde, vermelha e laranja) e um indicador azul onde cada led aceso indica 10% do espaço físico real já utilizado. Ou seja, basta olhar para ele para saber o que fazer.

O Drobo em si não é um NAS (Network Attached Storage – Storage anexado à rede). Para torná-lo um NAS é necessário outro produto chamado DroboShare que é basicamente um mini-computador, num design bem pequeno, que permite compartilhar o Drobo à uma rede. Você pode adquirir esse produto ou simplesmente ligá-lo a qualquer computador na rede. No meu caso, o Mac Mini é um excelente micro para ser um servidor caseiro. É pequeno, silencioso, consumo adequado de energia, e por isso vou manter os dois conectados e ligados o tempo todo. Com recursos com o Back to My Mac que vem no Mobile Me, consigo ter acesso a ele, de forma segura usando um canal encriptado, de qualquer lugar a partir do meu Macbook, seja do escritório, seja de algum hotel, aeroporto, etc. Muito conveniente.

Ainda tem pouco tempo de uso, esse tipo de produto precisa de meses para realmente começar a mostrar seu valor, mas para mim já valeu a pena o investimento.

Conclusão

Definitivamente estou muito contente com esta solução. Com o tempo esse tipo de solução deve ficar mais barata. Já está mais acessível do que era quando foi lançado, se não me engano era na faixa dos USD 500 ou mais. Além disso discos de 1TB há 3 anos eram muito caros. Hoje os discos de 2TB estão ficando acessíveis.

Ou seja, discos, assim como memória RAM e pendrives, estão literalmente baratos. São ítens que já foram bastante comoditizados. Pensando que a velocidade dos provedores deve crescer, que o nível de downloads deve aumentar, que o preço dos drives está caindo, a dinâmica de trocar de drives deve ser mais comum e a preocupação em manter tanto volume sem redundância é muito pior. É exatamente esse tipo de proteção contra o tempo que o Drobo vende. É isso que estou pagando.

Esta solução é mais do que adequada para uma pessoa física, como um storage para residências. Deve também ser mais do que suficiente para micro-empresas que precisam de storage para um servidor compartilhado de arquivos. Para pequenas empresas que lidam com volumes maiores de dados como estúdios, produtoras, vocês vão querer o Drobo Pro. É a mesma coisa mas em vez de 4 slots ele tem espaço para até 8 drives paralelos, permitindo inclusive montar o storage usando iSCSI via Gigabit Ethernet.

Para empresas média ou grandes, claro, não é esta a solução que você precisa. Procure storages de verdade, de grande porte, com hardware especializado. Além disso, lembrar que o Drobo não é a mesma categoria de produto que um HP Mediasmart. As características que mencionei no “Disclaimer” acima não se aplicam a quase nenhum outro produto. A maioria dos “storages” vendidos ao consumidor não são mais do que um HD SATA com um case glorificado. Pior ainda quando eles vendem um case com 2 HDs configurados em mirror como um striped set, onde se você perde um drive, perde todos os dados.

Finalmente, esta solução ainda não é completa. É o suficiente para uma residência. Mas se você tem uma micro-empresa e tem dados valiosos, você vai querer backup on-site e off-site (ou seja, guardado fisicamente fora do seu escritório). De nada adianta um backup onsite se seu escritório pegar fogo, ou se sofrer um roubo e ele for levado embora. Sempre garanta que seus dados estejam seguros fora daqui. No meu caso, residencial, é por isso que eu pago por um Mobile Me, para que meus dados mais importantes como meus e-mails estejam off-site, como contingência.

[Rails Summit 2009] Palestrante Bryan Liles

Fri, 18 Sep 2009 09:29:47 PDT

English translation: click here

Bryan Liles ficou bastante conhecido depois do Ruby Hoedown de 2008 com sua palestra Test All the Fucking Time cunhando o termo “TATFT”.

RailsConf 2009 – Mensagem de Bryan Liles para Brasileiros from Fabio Akita on Vimeo.

Ele virá falar sobre boas práticas de programação, baseado numa séria que começou recentemente no seu blog Smartic.us, chamado #yerdoinitwrong (literalmente, “voceestafazendoerrado”). Veja a apresentação da série:

#yerdoinitwrong intro from Bryan Liles on Vimeo.

O primeiro episódio fala sobre enviar os logs do Rails para um servidor remoto usando syslog, e recomenda o excelente Splunk, que eu também gosto. Não perca os episódios.

Não deixe de trocar figurinhas com ele durante o Rails Summit! Inscreva-se já!

Speaker Bryan Liles

Bryan Liles became very well known after his talk Test All the Fucking Time at Ruby Hoedown 2008, coining the term “TATFT”.

RailsConf 2009 – Bryan Liles message to Brazilians from Fabio Akita on Vimeo.

He’ll come to talk about best practices in software development, based on the series he recentely started at his blog Smartic.us called #yerdoinitwrong. Watch his introduction to the series:

#yerdoinitwrong intro from Bryan Liles on Vimeo.

The first episode talks about sending your Rails logs to a remote server using syslog, and he even recommends the excellent Splunk, which I like as well. Don’t miss his episodes.

And come to the Rails Summit to talk and exchange information with him! Register now!

[Rails Summit 2009] Palestrante Leonardo Borges

Thu, 17 Sep 2009 15:51:48 PDT

English translation: click here

A partir de hoje vou colocar alguns posts sobre alguns dos palestrantes do Rails Summit Latin America 2009. Não deixe de se inscrever! Dias 13 e 14 de Outubro, em São Paulo.

Leonardo Borges é desenvolvedor com 9 anos de experiência, já trabalhou em empresas de portes variados criando aplicações corporativas especialmente em Java. Atualmente vive em Madrid e trabalha com Ruby On Rails na Mirai España onde, dentre outros projetos, participa da iniciativa JRuby de integrar código legado com Rails. Escreve no seu blog sobre desenvolvimento de software e temas relacionados.

AkitaOnRails: Como você encontrou Ruby/Rails, o que foi que mais te atraiu?

Foi no início de 2007. Lendo blogs e notícias na internet cheguei no site oficial do Rails e vi o famoso vídeo Creating a weblog in 15 minutes. Fiquei impressionado! Aquele vídeo foi capaz de vender nao só a produtividade que o Rails proporciona, mas o nível de expressividade ao qual podemos chegar em Ruby.

AkitaOnRails: Quais assuntos mais te interessa atualmente e por quê?

Devido à natureza dos projetos aqui na empresa – um mix de Ruby e Java – tenho me interessado bastante em JRuby e a JVM de uma maneira geral, estudando também alternativas como Scala.

AkitaOnRails: Sobre o que trata sua palestra e para que tipos de desenvolvedores é mais indicado?

Eu acredito que JRuby veio pra ficar e que uma de suas maiores forças está em atrair empresas/desenvolvedores já acostumados ao mundo Java. Para isso uma integração precisa e simples entre Ruby e Java deve ser possível.

Na minha palestra “JRuby no mundo corporativo” vou mostrar como essa integração pode ser feita para dar uma nova roupagem a um sistema legado usando JRuby on Rails.

Essa sessão é para qualquer desenvolvedor Ruby interessado em rodar suas applicaçoes na JVM. No entanto, se você está trabalhando com Java no momento e está pensando como pode introduzir Ruby na sua empresa, essa palestra pode ser particularmente útil.

AVISO: Você verá fontes Java e XML nessa sessão! :P

Speaker Leonardo Borges

Starting off today, I’ll post about some of the speakers for Rails Summit Latin America 2009. Register today! It’s gonna be at São Paulo, Brazil, October 13th and 14th.

Leonardo Borges is a developer with 9 years of experience. He’ve been working for several companies creating enterprise applications specially with Java. He currently lives in Madrid, where he works with Ruby on Rails at Mirai España where, among other projects, colaborates in the JRuby initiative to integrate legacy code with Rails. He writes in his blog about software development and related subjects.

AkitaOnRails: How did you find Ruby/Rails, what attracted you the most?

It was in the beginning of 2007. By reading blogs and news on the internet I arrived at the Rails official website where I saw the famous Creating a weblog in 15 minutes screencast. I was impressed! That video was able to sell not only the productivity that Rails delivers, but also the level of expressiveness where we can achieve in Ruby.

AkitaOnRails: What subjects most interest you and why?

Due to the nature of the projects I have in my company – a mixture of Ruby and Java – I’ve very interested in JRuby and the JVM in general, studying alternatives such as Scala as well.

AkitaOnRails: What is the subject of your talk and what kind of developers will benefit the most?

I believe that JRuby will stay for a long time and one of its major strengths is to attract companies/developers already used to the Java world. For that end, a precise and simple integration between Ruby and Java is necessary.

In my talk “JRuby in the enterprise” I’ll show how that integration can be achieved to bring new life to a legacy system using JRuby on Rails.

This session is recommended to any Ruby developer interested in running his applications on the JVM. On the other hand, if you’re currently working with Java and trying to figure out how to introduce Ruby in your company, this talk can be particularly useful.

Warking: You’ll see lots of Java and XML source code in this talk! :P

[Rails Summit 2009] O Trailer mais Esperado!

Thu, 17 Sep 2009 08:06:55 PDT

Imagino que quem viu o Teaser Trailer de ontem ficou curioso. O pessoal que participou do Dev in Rio viu uma versão “especial” em primeira mão alguns dias atrás, agora aí vai a versão oficial:

E você, já se inscreveu no Rails Summit Latin America 2009 ?

[Tradução] Os problemas do pensamento do Visual Studio (e outras IDEs)

Wed, 16 Sep 2009 22:57:15 PDT

De tempos em tempos alguém me pergunta algo do tipo “Que IDE você usa para programar em Ruby?” E todos ficam surpresos ou frustrados quando eu digo “Nenhum, apenas um editor de textos competente.” Parece que a maioria dos programadores de Visual Basic, Delphi, Java, C#, VB.NET, simplesmente não conseguem sair do dogma dos IDEs com IntelliSense.

Eu, felizmente, comecei a programar dBase numa era onde o máximo em editor de textos era o Wordstar. No DOS eu usei EDLIN e depois o Edit que vinha nos DOS acho que 5.0. Quando fui programador Clipper no começo da década de 90, meu editor favorito era o Norton Editor. Somado a ferramentas como Sidekick, eu tinha a estação de desenvolvimento mais poderosa que se poderia querer: um editor de textos e só.

Quando o Java surgiu, um IDE com capacidades de auto-complete eram obrigatórias. Em .NET a mesma coisa, e pelas mesmas razões. Aqui eu traduzo a palestra entitulada O Visual Studio estraga nossas mentes?, apresentada no NYC .NET Developer’s Group, em 20 de Outubro de 2005 por Charles Petzold. Ele faz uma longa análise dos fundamentos de porque um programador viciado nos dogmas impostos pelo Visual Studio está se tornando um programador ruim.

Atualmente, eu programo apenas Ruby (e outras coisas como Javascript de vez em quando) apenas no Textmate, um competente editor de textos, reminiscente de inspirações em Emacs e Vim, outros dois excelentes editores. E não sinto falta de Eclipses, Netbeans ou qualquer coisa desse tipo e, obviamente, nenhuma falta do Visual Studio. Ah sim, precisar de auto-complete só mostra uma coisa: que as APIs estão sendo muito porcamente desenhadas ultimamente, tornando-as ridiculamente longas!

Recomendo ler o artigo inteiro, pois só traduzi as partes relevantes ao meu ponto. Vamos à tradução:

PS: Vale a pena descrever o paradoxo: não dá para efetivamente ser produtivo em .NET sem Visual Studio, em Java sem Eclipse/Netbeans/etc ou ObjC sem XCode. Isso é um fato. Na prática mesmo, a solução não é fazer C# em Notepad. Esse é o ponto a se pensar ;-)

Proliferação de APIs

Vinte anos atrás, em Novembro de 1985, o Windows 1.0 foi lançado com cerca de 400 funções documentadas. Dez anos depois, o Windows 95 teve bem mais de mil.

Hoje (em Outubro de 2005), estamos prontos para o lançamento oficial do .NET Framework 2.0. Tabulando somente o MSCorLib.dll e aqueles assemblies que começam com a palavra System, temos mais de 5.000 classes públicas que incluem mais de 45.000 métodos públicos e 15.000 propriedades públicas, sem contar os métodos e propriedades herdados e não sobrescritos. Um livro que listasse os nomes, valores de retorno e argumentos destes métodos e propriedades, uma por linha, teria cerca de mil páginas.

Se você escrevesse cada uma das 60.000 propriedades e métodos em cartões de 7 por 12 centímetros com uma pequena descrição do que fazem, teria uma pilha de 12 metros. Estes 60.000 cartões, alinhados de ponta a ponta – pelo comprimento de 12cm – poderia cercar o Central Park (quase), e eu ouvi que isso será realmente um projeto de arte pública no próximo verão.

Pode qualquer programador dominar 60.000 métodos e propriedades? Acho que não. Uma solução, é claro, é a especialização. Eu mesmo me especializei. Esta noite, eu espero que ninguém me faça perguntas sobre Web Forms ou ASP .NET ou SQL Server, pois essas não são minhas especialidades. Eu faço Windows Forms, e minha linguagem é C#.

IntelliSense

Visual Studio tem tentado atenuar o problema da proliferação de classes, métodos e propriedades com um recurso chamado IntelliSense. Isso certamente coloca a informação ao nosso alcance, se você pensar em seus dedos no sentido figurado como aquele lugar na tela onde o cursor do teclado está.

Como outras tecnologias viciantes, eu tenho um relacionamento de amor / ódio com o IntelliSense, e quanto mais eu o desprezo mais o uso, e quanto mais eu o uso, mais revoltado fico com a forma como fiquei viciado, e quanto mais viciado fico, mais eu desejo que isso nunca tivesse sido inventado.

Apenas no caso de você ter estado fora das trincheiras por algum tempo, o IntelliSense é a culminação de algumas tentativas anteriores em tecnologias de completar código. Se você digitar um nome de objeto e um ponto, por exemplo, obterá um menu de rolagem com uma lista de todos os métodos públicos, propriedades e eventos para essa classe, e quando você escolhe um nome de método e abre um parêntese, poderá obter as sobrecargas com vários argumentos, e uma dica descrevendo o que o método faz.

IntelliSense é considerado por alguns como a inovação de programação mais importante desde a cafeína. Ele funciona especialmente bem com .NET porque o Visual Studio pode usar reflexão para obter todas as informações que precisa das DLLs que você especificou como referências.

Na verdade, o IntelliSense tornou-se o primeiro aviso quando você não incluiu devidamente uma referência DLL ou uma diretiva using no topo do seu código. Você começa a digitar e o IntelliSense aparece com nada. Daí já sabe imediatamente que algo está errado.

E, no entanto, o IntelliSense também está ditando a forma como programamos.

Por exemplo, por muitos anos os programadores têm debatido se é melhor codificar de cima para baixo, onde basicamente você começa com a estrutura geral do programa e, eventualmente, o código das rotinas mais detalhadas na parte inferior ou, alternativamente, a abordagem de baixo para cima, onde você começa com as funções de nível baixo e prossegue para cima. Algumas linguagens, como Pascal clássico, basicamente impõe uma abordagem de baixo para cima, mas outras linguagens não.

Nota do Akita: Na comunidade Ruby on Rails, na vertente que adotou o Cucumber como ferramenta Ágil, o conceito de Behavior Driven Development (BDD) nos leva a programar de cima para baixo, que hoje é considerado uma forma muito mais eficiente de desenvolvimento, iniciando pelas User Stories, indo para a interface com o usuário, depois as rotas, os controllers, os models e só então as tabelas no banco, por exemplo.

Bem, o debate está terminado. Para o IntelliSense funcionar corretamente, programação de baixo para cima é melhor. O IntelliSense quer cada classe, cada método, cada propriedade, cada parâmetro do método, todas as variáveis locais adequadamente definidas antes de se referir a elas. Se esse não for o caso, então ele tentará corrigir o que você está digitando, usando algo que foi definido, e que provavelmente é simplesmente errado.

Por exemplo, suponha que você está digitando um código e decide que precisa de uma variável chamada id, e em vez de defini-la primeiro, você começa a digitar uma instrução que começa com id e um espaço. Eu sempre digito um espaço entre a minha variável e o sinal de igual. Como id não está definido em nenhum lugar, o IntelliSense encontrará algo que começa com estas duas letras que está sintaticamente correta, de acordo com as referências, namespaces, e o contexto de seu código. No meu caso particular, o IntelliSense decide que eu realmente queria definir uma variável do tipo de interface IDataGridColumnStyleEditingNotificationService, uma interface que eu nunca tive a oportunidade de usar.

No lado positivo, se você realmente precisa definir um objeto do tipo IDataGridColumnStyleEditingNotificationService, tudo que precisa fazer é digitar id e um espaço.

Se isso é errado, você pode eliminar o código proposto pelo IntelliSense e voltar ao que digitou originalmente com a combinação de teclas Ctrl-Z para desfazer. Eu gostaria de bater na mão dele e dizer “Não”, mas Ctrl-Z é a única coisa que funciona. Quem poderia supor que Ctrl-Z se tornaria uma das teclas mais importantes na utilização de modernas aplicações do Windows? Ctrl-Z funciona no Microsoft Word como, bem, quando o Word é excessivamente agressivo consertando sua digitação.

Mas a implicação aqui é impressionante. Para o IntelliSense começar a trabalhar direito, você não apenas deve codificar em uma estrutura de baixo para cima, mas dentro de cada método ou propriedade, também deve escrever código linearmente do início ao fim – exatamente como se estivesse usando o editor de linhas do velho DOS, o EDLIN. Você deve definir todas as variáveis antes de usá-las. Não mais saltando para qualquer lugar em seu código.

Nota do Akita: por isso é tão desconfortável exercitar Test Driven Development (TDD) com IDEs: TDD exige programação de cima para baixo, primeiro criando testes que falham para depois criar o código que a satisfaz. A IDE simplesmente não gosta dessa ordem e exige malabarismo para sair disso.

Não é que o IntelliSense está nos ensinando a programar como uma máquina, é só que o IntelliSense seria muito mais feliz se assim o fizéssemos.

E eu acho que isso está nos tornando mais idiotas. Em vez de descobrir exatamente o método que eu preciso, ou em vez de tentar lembrar um nome de propriedade indescritível, encontro-me a percorrer as possibilidades que o IntelliSense oferece, à procura de um nome familiar, ou pelo menos algo que parece se encaixar.

Eu não preciso lembrar mais nada. O IntelliSense se lembrará para mim. Além disso, eu justifico a mim mesmo que não quero aqueles 60.000 métodos e propriedades bagunçando minha mente. A minha saúde mental global será sem dúvida melhor sem eles, mas ao mesmo tempo, estou impedido de alcançar um estilo fluido de codificação porque ela não vem inteiramente da minha cabeça. Minha codificação tornou-se um diálogo constante com o IntelliSense.

Então eu não acho que o IntelliSense está nos ajudando a nos tornar programadores melhores. O objetivo real é para nos tornarmos programadores mais rápidos, o que também significa que está barateando nosso trabalho.

Claro, eu poderia sempre apenas desligá-lo.

E andar descalço? De jeito nenhum!

IntelliSense é uma tecnologia inevitável. Se a Microsoft não tivesse feito isso, alguém teria. Os seres humanos nunca foram inclinados a abster-se de perseguir certas tecnologias, pois eles podem ter repercussões infelizes.

Código Gerado

Não só o Visual Studio tenta completar código que estamos digitando, mas há muitos anos, o Visual Studio quis gerar o código para nós. Se selecionarmos um novo projeto de tipo Aplicativo Windows, por exemplo, e dar-lhe um nome e um local em uma unidade de disco, o Visual Studio gerará código suficiente para que este projeto seja imediatamente compilável e executável.

De alguma forma, nós fomos convencidos de que esta é a maneira correta de programar. Eu não sei porquê. Pessoalmente, acho que iniciar um programa com um arquivo de código fonte vazio é muito agradável. Eu gosto de escrever as preliminares e, em seguida, a função principal, ou o método main. O momento em que eu possa realmente usar alguma ajuda não é quando estou começando um programa, mas quando estou tentando terminar. Onde está o Visual Studio então?

Vamos para o Visual Studio 2005 em nossa imaginação e criar um programa C# Windows Forms – um projeto do tipo Aplicação Windows – e analisar o código.

Primeiro, vemos que o Visual Studio ligou o nosso programa a um grupo de bibliotecas de vínculo dinâmico que ele acha que precisamos. Criou referências não somente aos assemblies System, System.Drawing e System.Windows.Forms que são necessários em qualquer aplicativo não-trivial de Windows Forms, mas também System.Data, System.Deployment e System.Xml, independentemente se seu programa necessita dessas DLLs ou não. Estas referências extras não fazem nenhum mal real, exceto se alguém examina o programa – talvez para fazer algumas alterações após o programador original ter ido embora – e assume que a aplicação requer estas referências. Agora há confusão, porque existem referências a DLLs que o programa realmente não precisa.

Entre outros arquivos, o Visual Studio cria um Form1.cs que gentilmente permite a você, o programador, modificar. Esse é o código fonte do arquivo onde os manipuladores de eventos vão para controles no formulário principal. Nós vemos um monte de directivas using no topo com os namespaces para as necessidades do programa. Os namespaces normais para os programas do Windows Forms são System, System.Drawing e System.Windows.Forms, mas o Visual Studio também inclui System.Collections, System.ComponentModel, System.Data e System.Text, alguns dos quais são úteis com certeza, mas se o programa realmente não usar qualquer uma das classes nesses namespaces, eles são apenas ruídos de distração.

O Visual Studio também inclui todo o código que gera em um namespace onde é dado o mesmo nome que o nome do projeto. Claro, eu entendo completamente o valor de ter um namespace para DLLs, mas por que ter um namespace para as aplicações? Eu pensei muito, e não consigo entender.

Eu tenho falado sobre código, mas quando você cria um novo projeto Windows Forms, o Visual Studio não coloca qualquer um dos arquivos de código fonte na sua frente. Em vez disso, ele coloca uma exibição de design de um formulário onde você deve começar a preencher de forma interativa com controles.

O Visual Studio também cria um arquivo chamado Form1.Designer.cs, e em algumas versões beta do Visual Studio 2005, esse arquivo não foi sequer listado entre os arquivos do projeto, por padrão. Este é o arquivo onde o Visual Studio insere código gerado quando você cria o formulário. O Visual Studio realmente não quer que você mexa com esse arquivo e por boas razões. Ele espera que este código gerado esteja em um determinado formato e, se você mexer nele, pode não ser capaz de lê-lo de volta na próxima vez que abrir o projeto.

(…)

Design Interativo

A maioria das coisas realmente inovadoras de design interativo, encontrou sua primeira manifestação no Visual Basic de Windows, e aqui é onde eu comecei a ficar nervoso sobre onde a programação no Windows estava indo. Não só você poderia mover um botão em seu formulário, e de forma interativa posicioná-lo e acertar seu tamanho do jeito que quisesse, mas se clicasse no botão, o Visual Basic geraria um manipulador de eventos para você, deixando-o digitar o código.

Isso me incomodou porque o Visual Basic estava tratando de um programa não como um documento completo e coerente, mas como pequenos trechos de código anexado para objetos visuais. Isso não é programar. Não é isso que o compilador vê. Como é que alguém obtêm um senso de um programa completo? Me deixou perplexo.

Eventualmente, o material de desenho interativo encontrou seu caminho para o desenvolvimento com C++ e Microsoft Foundation Classes, e lá, eu realmente acreditei, a geração de código foi usado para esconder um monte de coisas cabeludas do MFC que realmente ninguém queria ouvir falar.

Para um autor que escreve livros de programação, todo este material apresenta um dilema. Como você escreve um tutorial de programação? Você se concentra sobre o uso do Visual Studio para desenvolver aplicativos? Sinceramente, eu achei muito difícil escrever frases como “Agora arraste o objeto botão da caixa de ferramenta para a sua caixa de diálogo” e ainda sentir como se estivesse ensinando programação. Eu nunca escrevi sobre C++ e MFC, parcialmente porque MFC parecia um invólucro fino sobre a API do Windows e muito mal orientado a objetos. Eu continuei a rever edições posteriores do Programming Windows sob a suposição de que os seus leitores fossem programadores como eu, que preferiam escrever seu próprio código do zero.

Até mais, Resource Script

Eu comecei a olhar para o beta do .NET 1.0 e Windows Forms, no verão de 2000, e era claramente mais orientado a objeto do que o MFC jamais poderia ser. Gostei disso. Eu também estava intrigado que o Resource Script tinha desaparecido completamente. Você criava e montava controles nas caixas de diálogo – agora reunidos sob o termo mais global de “formulários” – ali mesmo em seu código. Claro que, mesmo no Windows 1.0, você poderia criar controles no código, e a primeira edição do Programming Windows tem alguns exemplos. Mas simplesmente não era muito agradável, porque toda criação de controles envolvia uma chamada para a função CreateWindow de 11 argumentos. Mas a criação de controles via código no Windows Forms era um piscar de olhos.

O que é agradável sobre criar e manipular controles no código é que você os está criando e manipulando no código. Suponha que você queira uma coluna de dez botões igualmente espaçados do mesmo tamanho exibindo nomes de cores. Em um programa, você pode realmente armazenar os dez valores de cores em um só lugar. É chamado um array. Há também uma excelente forma de criar e posicionar estes dez botões. É chamado de um loop for. Isso é programação.

Mas o Visual Studio não quer que você use arrays ou loops for para criar e posicionar esses botões. Ele quer que você use o designer, e ele quer gerar o código para você e escondê-lo onde você não possa vê-lo.

Quase vinte anos após o primeiro Editor de diálogo, o Visual Studio agora é o culpado, que gera código feio e o avisa para que não se meta com ele.

Se você tentar ler este código, não é assim tão fácil, porque cada classe e estrutura é precedido por um namespace completo:

1	System.Windows.Forms.Button button1 = System.Windows.Forms.Button ();

Claro, nós sabemos porque o Visual Studio precisa fazer isso. Em teoria, é possível para você adicionar à caixa de ferramentas do Visual Studio outro controle Button chamado de outra DLL com outro namespace, e deve haver uma maneira de diferenciá-los.

Como o Visual Studio está gerando código baseado nos controles que você selecionar, ele dá nomes padrões aos controles, como button1, button2, button3, label1, label2, label3, textBox1, textBox2, textBox3.

Claro, o Visual Studio permite que você altere o nome da variável. Você pode alterar a propriedade Nome do controle, e isso se torna não apenas a propriedade Nome do objeto botão, mas também o seu nome de variável.

Os programadores realmente fazem isso? Eu tenho certeza que alguns fazem, mas também estou certo que muitos não o fazem. Como eu sei? Dê uma olhada em alguns dos códigos de exemplo que vem da Microsoft. Lá você verá button1, button2, button3, etc. E, no entanto, todos concordam que um dos elementos mais importantes de código auto-documentado está em dar nomes significativos às suas variáveis e objetos.

Se o Visual Studio realmente quisesse que você escrevesse código bom, toda vez que você arrastasse um controle no formulário, uma janela pop-up irritante diria: “Escreva um nome significativo para este controle.” Mas o Visual Studio não está interessado em fazer você escrever código bom. Ele quer que você escreva código rápido.

Enquanto estou no assunto de nomes de variáveis, eu deveria dizer algo positivo sobre o Visual Studio. O Visual Studio 2005 tem uma facilidade totalmente esplêndida de renomear variáveis. Você sabe como às vezes realmente quer mudar o nome de uma variável para estar mais em sintonia com sua função real no programa, mas você está receoso por causa dos possíveis efeitos secundários de buscar e substituir? Bem, esta nova renomeação de variáveis evita tudo isso, e também irá lhe dizer se você está renomeando algo para um nome que já existe. Espero que as pessoas se aproveitem disso para renomear seus controles para algo diferente dos padrões do Visual Studio.

Propriedades usadas Demais

Outro problema com a geração de código do Visual Studio é que todo controle vira uma propriedade na classe onde é criado. Esta é uma prática odiosa de programação, e realmente me incomoda que programadores possam estar olhando o código gerado pelo Visual Studio para aprender técnicas de programação adequada, e é isso que eles vêem.

Nos dias anteriories à orientação-a-objetos de programação C, tínhamos variáveis locais e variáveis globais, variáveis dentro de funções e variáveis fora de funções. Um dos objetivos da boa programação em C estava em manter o número de variáveis globais ao mínimo. Como qualquer variável global poderia ser modificada por qualquer função, era mais fácil entender um programa se simplesmente não houvesse muitas delas – se as funções estritamente se comunicassem entre si através de argumentos e valores de retorno.

Às vezes, no entanto, os programadores C ficavam um pouco, digamos, sonolentos, e faziam uma série de variáveis globais que realmente não precisavam existir, porque era mais fácil dessa maneira. Ao invés de acrescentar um argumento extra para uma função, porque armazená-lo como uma global?

As variáveis globais basicamente desapareceram em programação orientada-a-objetos, exceto que propriedades são agora as novas variáveis globais e podem ser abusadas de forma muito ruim.

Um dos princípios básicos de programação orientada-a-objetos está em esconder dados. Isso geralmente se aplica entre classes. Classes não devem expor tudo o que têm. Elas deveriam ter uma interface pública o menor possível, e outras classes devem saber apenas o que precisam saber. Mas o princípio de ocultamento de dados é importante também dentro de uma classe. Métodos devem ter acesso limitado aos dados que outros métodos estão usando. Em geral, as variáveis devem ser locais para um método a menos que haja uma razão específica de porque precisam ser acessados de qualquer outro método.

Quando você cria um objeto usando o operador new, a quantidade de armazenamento alocada no heap para o objeto deve ser suficiente para acomodar todas as propriedades definidas na classe que está criando o objeto e todas as classes ancestrais. As propriedades basicamente definem o tamanho do objeto na memória. Eu sei que estamos muito além do ponto de se preocupar com cada byte de armazenamento, mas quando você olha para as propriedades que definiu em sua classe, deve estar se perguntando: Será que todo este material realmente precisa ser armazenado com cada objeto no heap? Ou restringi com sucesso as propriedades às informações necessárias para manter o objeto?

Alguém me disse que gosta de armazenar objetos como propriedades porque tem medo do garbage collector do .NET limpar tudo que não estiver em definições apropriadas de propriedade. Depois de anos definindo muito poucas propriedades em .NET, posso lhes dizer que isto não é um problema. O garbage collector do .NET só excluirá objetos que não são mais referenciados em qualquer parte do programa. Se você ainda pode acessar um objeto de alguma forma, ele não é elegível para coleta de lixo.

Em teoria, nenhuma controle-filho criado como parte de um formulário deve ser armazenado como uma propriedade porque o pai – geralmente um formulário – armazena todos os seus controles-filho na coleção chamada Controls, e você pode fazer referência a cada controle indexando a propriedade Controls usando inteiros ou a propriedade texto Nome que lhe foi atribuída ao criar o controle. E aqui mais uma vez você está muito melhor se os controles tiverem nomes significativos e não button1, button2, button3, label1, label2, label3 …

Se um determinado objeto é definido como uma propriedade ou uma variável local é algo que nós, como programadores devemos estar pensando a cada objeto que criamos. Um label que tem o mesmo texto durante toda a duração do formulário pode ser facilmente local. Para um rótulo cujo texto é o conjunto de um manipulador de eventos de algum outro controle, provavelmente é mais conveniente armazenar como uma propriedade.

É muito simples. Mas o Visual Studio não quer que você pense sobre isso. O Visual Studio quer tudo armazenado como uma propriedade.

Visual Studio Desmistificado

Mesmo se o Visual Studio gerasse código imaculado, ainda haveria um problema. Como ele está gerando o código, também ergue muros entre o código e o programador. Ele implica que esta é a única maneira que você pode escrever um programa Windows moderno ou web, porque há certos aspectos da programação moderna que só ela conhece. E o Visual Studio aumenta essa impressão, incluindo código clichê que contém material que nunca foi realmente discutido de forma adequada, nos tutoriais ou documentação que a Microsoft oferece.

Torna-se imperativo para mim, como professor de programação Windows Forms e programação de Avalon, deliberadamente ir na direção oposta. Eu sinto necessidade de desmistificar o que o Visual Studio está fazendo e demonstrar como você pode desenvolver esses aplicativos escrevendo seu próprio código e, se você quiser, compilar esse código na linha de comando totalmente fora do Visual Studio.

Nos meus livros de formulários do Windows, eu digo ao leitor para não escolher Aplicação Windows quando se inicia um novo projeto Windows Forms, mas escolher a opção Projeto Vazio em vez disso. O projeto vazio não cria nada além de um arquivo de projeto. Todas as referências e todo o código deve ser adicionado explicitamente.

Estou prestando um serviço público, mostrando aos programadores como escrever código de uma maneira que é diametralmente oposta às funcionalidades incorporadas na ferramenta que eles estão usando? Eu não sei. Talvez isto seja errado, mas não vejo outra alternativa.

(…)

Os Prazeres Puros de Código Puro

Alguns meses atrás – talvez como um antídoto para toda essa overdose de Windows Forms e programação Avalon que tenho feito – eu comecei a programar em C novamente. Só um pouquinho. Uma revista que li – o semanário britânico New Scientist – tem uma parte chamada de “Enigma”, que apresenta um pequeno enigma de matemática. Aqui está um curto de Junho passado: “Qual é o maior inteiro cujos algarismos são todos diferentes (e não incluem 0), que é divisível por cada um dos seus dígitos individuais?” Se você resolve um dos problemas Enigma, pode enviar a sua solução, e uma é escolhida aleatoriamente em uma determinada data, e se o seu for escolhido você ganha USD 25 e uma menção na revista.

Estes problemas Enigma realmente me incomodaram durante anos, porque eles sempre me pareceram ser resolvidos escrevendo um programa curto e testando as possibilidades e, por alguma razão, isso me parecia absurdo.

Alguns meses atrás eu decidi que poderia realmente ser interessante resolver os problemas com código, e em seguida enviar os programas e soluções no meu site um dia depois do prazo, mas cerca de uma semana antes da resposta aparecer impressa.

Eu decidi usar o bom e velho ANSI C, e editar o código-fonte no Bloco de notas – que não tem nenhuma noção de IntelliSense e nenhuma noção de qualquer outra coisa – e compilar na linha de comando usando tanto o compilador Microsoft C e o compilador GNU C.

O que é interessante sobre este projeto é que eu não tenho que olhar nada. Eu tenho codificado em C há 20 anos. Foi a minha linguagem preferida antes de C#. E isso é apenas pura codificação algorítmica com saída de texto simples. É somente conteúdo.

Eu também descobri que os problemas realmente exigem uma reflexão antes de codificá-los. Muitas vezes, o número total de combinações é proibitivo. Você realmente tem que trabalhar. Você não quer escrever um programa que precisa ser executado por uma semana antes de chegar à instrução printf. Por exemplo, se o problema que citei: “Qual é o maior inteiro cujos algarismos são todos diferentes (e não incluem 0) que é divisível por cada um dos seus dígitos individuais?” Isso realmente ajuda a perceber que este número inteiro não pode conter o dígito 5 se ele também contém qualquer dígito par, porque então o número será divisível por 10, e o último dígito seria 0, o que não é permitido. Assim, o número que estamos procurando provavelmente não inclui 5. O que imediatamente reduz as possibilidades por uma ordem de grandeza.

Mesmo após este processo preliminar, há ainda codificação para fazer, mas não há nenhuma API, não há classes, não há propriedades, não há formulários, não há controles, não há manipuladores de eventos, e não há definitivamente o Visual Studio.

É somente eu e o código e, por algum tempo, me sinto como um verdadeiro programador novamente.

[Rails Summit 2009] Teaser Trailer

Wed, 16 Sep 2009 05:35:49 PDT

Quem esteve no Dev in Rio 2009 e quem participou do Rails Summit 2008 sabe do que estou falando :-)

Aqui vai a história sobre isso, diretamente pelo Tapajós

Eu estava sentado junto com a galera do Rio vendo a morena passando de um lado para o outro e observando que ninguém se concentrava na palestra. Todo mundo estava fazendo a cobertura do evento no twitter e eu tive a idéia de pôr uma foto dela lá, provocando quem não veio ao evento.

Como eu era um novo usuário do twitter e achava meio estúpido o propósito dele de dizer o que se está fazendo eu sempre tentei subverter o uso dele e tive a idéia de fazer a mesma coisa com um repositório de código. Fui lá no github, criei o projeto, coloquei uma foto e publiquei o link no Twitter.

Nesse momento eu fui até o Chris Wanstrath (criador do github) e mostrei o projeto. Ele achou super engraçado e comentou que as pessoas achavam os usos mais estranhos possíveis para os repositórios e que isso era bem engraçado e fizemos uma pequena “aposta” que o projeto ia bombar.

Em poucos minutos minha caixa de e-mails estava lotada de pull request com dezenas e fotos e como estava bem complicado gerenciar tudo e ainda observa-la eu resolvi dar direito de commit a algumas pessoas e o projeto ganhou vida própria.

Meu medo era a morena ficar “P” e querer arrumar confusão. Era impossível voltar atrás! Mas felizmente ela ficou sabendo e não ligou, por isso o projeto continuou crescendo e até hoje continua sendo forkado

Por falar em fork, o Dr. Nic foi um dos que adorou o projeto e gravou um pequeno vídeo sobre ele.

Bem, O Rails Summit 2009 está chegando e eu estarei lá para dar continuidade ao projeto e se der tempo vou palestrar também.

Assistam a outros teasers do Rails Summit 2009 em http://www.youtube.com/user/AkitaOnRails e ajudem a promover o evento!

Não se esqueçam, o Rails Summit acontece dias 13 e 14 de Outubro, não deixem para se registrar na última hora!

[Off-Topic] A Argumentação através da Intimidação

Sat, 12 Sep 2009 08:40:26 PDT

Há um certo tipo de argumentação que, na verdade, não é uma argumentação, mas um meio de evitar o debate e extorquir o acordo de um adversário baseado em noções indiscutíveis. É um método de burlar a lógica usando pressão psicológica. Uma vez que é particularmente comum na cultura de hoje e continuará crescendo, é bom aprender a identificá-lo e estar em guarda.

Este método tem uma certa semelhança com a falácia ad hominem, vem da mesma raiz psicológica, mas é essencialmente diferente. A falácia ad hominem consiste em tentar contrariar um argumento acusando o caráter de seu proponente. Exemplo: “o candidato X é imoral, pois seu argumento é falso.”

O método de pressão psicológica consiste em ameaçar a integridade do caráter de um oponente usando seu próprio argumento, então contestando a argumentação, sem debate. Exemplo: “Só o imoral não vê que o argumento do candidato X é falso.”

No primeiro caso, a imoralidade do Candidato X (real ou inventado) é oferecido como prova da falsidade de seus argumentos. No segundo caso, a falsidade de seu argumento é afirmada de forma arbitrária e oferecida como prova de sua imoralidade.

Na selva epistemológica de hoje, esse segundo método é usado com mais freqüência do que qualquer outro tipo de argumento irracional. Deve ser classificado como uma falácia lógica e pode ser designado como “a argumentação através da intimidação”.

A característica essencial da argumentação através da intimidação é o seu apelo à auto-dúvida moral e sua dependência do medo, culpa ou ignorância da vítima. É usado na forma de um ultimato exigindo que a vítima renuncie à sua idéia sem discussão, sob pena de ser considerado moralmente indigno. O padrão é sempre: “Somente aqueles que são maus (desonestos, cruéis, insensíveis, ignorantes, etc) tem essas idéias.”

O exemplo clássico do argumento da intimidação é a história As Roupas Novas do Imperador

Nessa história, alguns charlatães vendem roupas inexistente ao Imperador, afirmando que a beleza incomum do vestuário os torna invisíveis para aqueles que são moralmente condenáveis de coração. Observe os fatores psicológicos necessários para fazer este trabalho: os charlatães confiam na auto-dúvida do Imperador; e ele não põe em dúvida essa afirmação, nem a sua autoridade moral. Ele se rende ao mesmo tempo, alegando que de fato enxerga as peças de vestuário, negando assim a evidência de seus próprios olhos e invalidando a sua própria consciência em vez de enfrentar uma ameaça à sua auto-estima precária. Sua distância da realidade pode ser avaliada pelo fato de que ele prefere andar nu na rua, exibindo as suas vestes inexistente para o povo, ao invés de arriscar incorrer na condenação moral de dois canalhas. As pessoas, motivadas pelo mesmo pânico psicológico, tentam ultrapassar um ao outro com exclamações em voz alta sobre o esplendor de suas vestes, até que uma criança grita que o rei está nu.

Este é o modelo exato do trabalho da Argumentação através Intimidação, como está sendo trabalhado em torno de nós hoje.

Todos já ouvimos e continuamos ouvindo esse tipo de coisa constantemente:

“Somente aqueles que não possuem instintos mais refinados falham em aceitar a moralidade do altruísmo.”
“Somente os ignorantes não sabem que a razão foi invalidada.”
“Somente os reacionários de coração negro podem defender o capitalismo.”
“Só sedendos por guerra podem opor-se às Nações Unidas.”
“Só os lunáticos ainda acreditam na liberdade.”
“Só os covardes não veem que a vida é um esgoto.”
“Só os superficiais procuram a beleza, felicidade, realização, valores ou heróis.”

Como exemplo de um campo inteiro de atividade baseada em nada além da argumentação através da intimidação, dou-lhe a arte moderna, onde, a fim de comprovar que de fato possuem o discernimento especial que somente a elite “mística” tem, a população tenta superar um ao outro em exclamações em voz alta do esplendor de alguns pedaço de lona borrados.

A argumentação através da intimidação domina discussões de hoje em duas formas. Em discursos públicos e impressos, ele floresce sob a forma de estruturas longas, envolventes, elaboradas de palavreado ininteligível, que transmitem nada exceto uma clara ameaça moral. (“Só os de mentalidade primitiva deixam de perceber que a clareza é simplificação excessiva.”) Mas, em particular, no dia-a-dia, ele vem sem palavras, nas entrelinhas, sob a forma de sons inarticulados contendo implicações não declaradas. Baseia-se, não no que é dito, mas em como se diz – não no conteúdo, mas no tom de voz.

O tom é geralmente de uma incredulidade beligerante ou desdenhosa. “Certamente você não é um defensor do capitalismo, não é?” E se isso não intimida a vítima em perspectiva, que responde, corretamente: “Eu sou” – o diálogo se segue mais ou menos assim:

“Ah, você não poderia ser! Não é verdade!
“Verdade”.
“Mas todo mundo sabe que o capitalismo está ultrapassado!”
“Eu não”.
“Ah, não pode ser verdade!”
“Já que eu não sei, você vai me dizer as razões para pensar que o capitalismo está ultrapassado?”
“Oh, não seja ridículo!”
“Vai me dizer as razões?
“Bem, se você realmente não sabe, não sou eu que poderia possivelmente lhe dizer!”

Tudo isso é acompanhado de sobrancelhas levantadas, de olhos arregalados, encolher de ombros, grunhidos, e todo arsenal de sinais não-verbais comunicando insinuações sinistras e vibrações emocionais de uma única espécie: desaprovação.

Se essas vibrações falham, se tais debatedores são desafiados, verifica-se que eles não têm argumentos, nenhuma evidência, nenhuma prova, nenhuma razão, nenhum motivo no qual fundamentar – que sua agressividade ruidosa serve para esconder o vácuo – que a argumentação através da intimidação é uma confissão de impotência intelectual.

O arquétipo primordial desta argumentação é evidente (e assim são as razões do seu recurso para o neo-misticismo da nossa era): “Para aqueles que entendem, nenhuma explicação é necessária; para aqueles que não entendem, nenhuma é possível”.

A fonte psicológica do que o argumento é metafísica social.

Um metafísico social é aquele que trata a consciência dos outros homens como superiores aos seus próprios e para os fatos da realidade. Para um metafísico social a avaliação moral de si próprio pelos outros é uma preocupação primária que substitui a verdade, fatos, razão lógica. A reprovação dos outros é tão terrível para ele que nada pode resistir ao seu impacto dentro da sua consciência, assim ele negaria a evidência de seus próprios olhos e invalidaria a sua própria consciência em prol da aprovação moral de qualquer charlatão vadio. Apenas um metafísico social poderia conceber tal coisa absurda como a esperança de ganhar um argumento intelectual insinuando: “Mas as pessoas não vão gostar de você!”

Estritamente falando, um metafísico social não percebe a sua argumentação em termos conscientes: ele acha isso “instintivamente”, pela introspecção, uma vez que representa a sua forma psico-epistemológica de vida. Todos nós já encontramos o tipo irritante de pessoa que não escuta o que alguém diz, mas às vibrações emocionais da voz do outro, ansiosamente traduzindo-os em aprovação ou reprovação para, em seguida, responder de acordo. Esta é uma espécie de argumentação auto-imposta através da intimidação, à qual um metafísico social se rende na maioria dos seus encontros humanos. E assim, quando ele encontra um adversário, quando suas premissas são contestadas, ele recorre automaticamente à arma que o assusta mais: a retirada da sua aprovação moral.

Uma vez que esse tipo de terror psicológico é desconhecido para homens saudáveis, isso pode ser considerado como argumentação através da intimidação, precisamente por causa da sua inocência. Sem entender o motivo da argumentação ou para acreditar que ele é apenas um blefe sem sentido, eles assumem que seu usuário tem algum tipo de conhecimento ou razões para apoiar suas afirmações aparentemente auto-confiantes, beligerantes, dando-lhe o benefício da dúvida – e são deixados em confusão perplexa. É assim que os metafísicos social vitimizam os jovens, os inocentes, a consciência.

Isto é particularmente prevalente nas salas de aula da faculdade. Muitos professores usam a argumentação através da intimidação para abafar o pensamento independente entre os estudantes, para fugir a perguntas que não conseguem responder, para desencorajar qualquer análise crítica de seus premissas arbitrárias ou qualquer desvio do status quo intelectual.

“Aristóteles? Meu querido companheiro” (um suspiro cansado) “Se você tivesse lido o trabalho do Professor Spiffkin” (respeitosamente) “da edição de janeiro de 1912 da revista Intellect, que” (com desdém) “obviamente você não leu, saberia” (levianamente) “que Aristóteles foi refutado.”

“Professor X?” (sendo X o nome de um distinto teórico de economia de livre empresa) “Você está citando o Professor X? Oh não, fala sério!” – seguido de uma risada sarcástica com a intenção de transmitir que o Professor X foi completamente desacreditado. (Por quem? Fim da discussão.)

Esses professores são freqüentemente assistidos pela brigada dos capangas dos “liberais” da sala de aula, que explodem em gargalhadas em momentos apropriados.

Em nossa vida política, a argumentação através da intimidação é o método quase exclusivo de discussão. Predominantemente, os debates políticos de hoje consistem de manchas e desculpas, ou intimidação e apaziguamento. O primeiro é geralmente (mas não exclusivamente) praticada pelos “liberais”, o segundo pelos “conservadores”. Os campeões, neste contexto, são os “liberais” republicanos que praticam ambas: a primeira, em relação a seus companheiros “conservadores” republicanos, a segunda, aos democratas.

Todas as manchas são argumentos de intimidação: eles consistem de afirmações depreciativas, sem qualquer indício ou prova, oferecidos como substitutos das evidências ou provas, visando à covardia moral ou credulidade impensada dos ouvintes.

A argumentação através da intimidação não é nova, tem sido utilizada em todas as idades e culturas, mas raramente em escala tão ampla quanto hoje. Ela é usada mais cruamente na política do que em outros campos de atividade, mas não se limita à política. Ela permeia toda a nossa cultura. É um sintoma de falência cultural.

Como é que alguém pode resistir a esse argumento? Existe apenas uma arma contra ela: a certeza moral.

Quando se entra em qualquer batalha intelectual, grande ou pequena, pública ou privada, não se pode buscar, desejar ou esperar aprovação do inimigo. Verdade ou mentira deve ser a preocupação exclusiva e o critério de julgamento – não a aprovação ou desaprovação de qualquer pessoa e, acima de tudo, não a aprovação dessas cujos padrões são o oposto do seu próprio. (obs: já viram aquelas argumentações que começam “Eu respeito muito você, mas …” – claramente buscando uma aprovação).

Deixe-me enfatizar que o argumento da intimidação não consiste em colocar julgamento moral em questões intelectuais, mas de substituir o julgamento moral pelo argumento intelectual. Avaliações morais estão implícitas na maioria das questões intelectuais; não é meramente permitido, mas obrigatório colocar um juízo moral quando e onde necessário; suprimir tal julgamento é um ato de covardia moral. Mas um julgamento moral deve sempre seguir e jamais anteceder (ou substituir), as razões em que se baseia.

Quando se dá razões para um veredito, se assume a responsabilidade por ele e coloca-se à disposição ao julgamento objetivo: se suas razões são erradas ou falsas, sofre-se as conseqüências. Mas, condenar sem fundamentação é um ato de irresponsabilidade, uma espécie de atropelamento e fuga moral, que é a essência da argumentação através da intimidação.

Observa-se que os homens que usam esse argumento são os que temem um ataque moral fundamentado mais do que qualquer outro tipo de batalha, e quando encontram um adversário confiante moralmente, eles são os mais altos em protestar que “moralização” deve ser mantida fora das discussões intelectuais. Mas, discutir o mal de uma forma que implica a neutralidade, é uma forma de aprová-la.

A argumentação através da intimidação ilustra porque é importante ter certeza das próprias premissas e da própria fundação moral. Ele ilustra o tipo de armadilha intelectual que aguarda aqueles que se aventuram sem uma análise completa, clara e consistente das próprias convicções, totalmente integrada até os fundamentos – aqueles que de forma imprudente pulam para a batalha, armados apenas com algumas noções flutuantes aleatórias em uma névoa do desconhecido, do não identificado, do indefinido, do não provado, e apoiado por nada além de seus sentimentos, esperanças e medos. A argumentação através da intimidação é seu maior inimigo. Em questões morais e intelectuais, não é suficiente estar certo: é necessário saber que está certo.

por Ayn Rand – último capítulo de “The Virtue of Selfishness”, 1964

[Off-Topic] Direitos do Homem

Wed, 09 Sep 2009 22:14:11 PDT

Normalmente eu não gosto de falar de política. Detesto. Sempre achei uma grande perda de tempo. Porém, diante das visões mais exacerbadas de populismo-esquerdismo, da ignorância quando se engrandece o socialismo-tirano cubano ou a ditadura totalitária venezuelana; diante do clamor por reestatização e os movimentos contra a privatização – todas calcadas na idéia de “o bem para o povo”, “pelo benefício da maioria”, “pela ajuda aos fracos” e outra baboseiras como essa, achei que poderia pelo menos oferecer uma pequena contribuição filosófica, traduzindo pelo menos mais um capítulo do livro de Ayn Rand, The Virtue of Selfishness que fala exatamente sobre esse tema, lembrando, claro, que ele foi escrito sobre o contexto dos anos 60. Mas é impressionante como as coisas não mudaram muito nesse sentido. Mas, antes, mais um trecho da introdução, a respeito da fundação do “egoísmo racional” do Objetivismo:

Observem a indecência do que se passa por julgamentos morais hoje. Um industrial que produz uma fortuna, e um bandido que rouba um banco são considerados igualmente imorais, uma vez que ambos procuraram riqueza para seu próprio benefício “egoísta”. Um jovem que abandona sua carreira, a fim de sustentar os pais e nunca ultrapassa o posto de escriturário de mantimentos é considerado moralmente superior ao jovem que sofre um esforço excruciante e alcança a sua ambição pessoal. Um ditador é considerado como moral, uma vez que as atrocidades indescritíveis que foram cometidos foram para beneficiar “o povo”, e não a si mesmo.

Observe o que este critério de benefício da moralidade faz na vida de um homem. A primeira coisa que ele aprende é que a moralidade é o seu inimigo, ele não tem nada a ganhar com isso, ele só pode perder; perda auto-infligida, dor auto-infligido e a mortalha cinza, debilitante de uma obrigação incompreensível é tudo o que ele pode esperar. Ele pode esperar que outros podem, ocasionalmente, sacrificar-se para seu benefício, como ele se sacrifica de má vontade a eles, mas ele sabe que o relacionamento vai trazer ressentimento mútuo, não prazer – e que, moralmente, sua perseguição de valores será como um intercâmbio de presentes de Natal indesejados, não escolhidos, onde nenhum é moralmente permitido comprar para si mesmo. Além dos momentos onde ele consegue realizar um ato de auto-sacrifício, ele não possui nenhum significado moral: a moral não toma conhecimento dele e não tem nada a dizer-lhe para orientá-lo nas questões cruciais de sua vida, é apenas a sua próprio vida pessoal, privada, “egoísta” e, como tal, é considerado ou mal, ou, na melhor das hipóteses, amoral.

…

Já que o egoísmo é a “preocupação com os próprios interesses,” a ética Objectivista utiliza esse conceito em seu sentido exato e mais puro. Não é um conceito que pode ser entregue aos inimigos do homem, nem para os equívocos irrefletidos, distorções, preconceitos e medos do ignorante e do irracional. O ataque ao “egoísmo” é um ataque à auto-estima do homem, desistir de um é desistir do outro.

Capítulo 12 – Direitos do Homem

Se alguém quiser defender uma sociedade livre – ou seja, capitalismo – ele deve entender que a fundação indispensável é o princípio do direito individual. Se alguém quiser suportar os direitos individuais, ele deve entender que o capitalismo é o único sistema que pode suportar e os proteger. E se alguém quiser medir o relacionamento da liberdade com os objetivos dos intelectuais de hoje, ele deve medí-lo pelo fato que o conceito de direitos individuais é evitado, distorcido, pervertido e raramente discutivo pelos chamados “conservadores”.

“Direitos” são um conceito moral, o conceito que fornece uma transição lógica dos princípios que norteiam as ações de um indivíduo para os princípios que orientam a sua relação com os outros, o conceito que preserva e protege a moralidade individual em um contexto social, a ligação entre o código moral de um homem e o código jurídico de uma sociedade, entre ética e política. Os direitos individuais são o meio para subordinar a sociedade à lei moral.

Todo sistema político é baseado em algum código de ética. A ética dominante da história da humanidade são variantes da doutrina altruísta-coletivista, que subordinava o indivíduo a alguma autoridade superior, seja mística ou social. Consequentemente, a maioria dos sistemas políticos eram variantes da mesma tirania estatista, diferindo apenas em grau, não em princípio básico, limitada apenas pelos acidentes da tradição, do caos, da luta sangrenta e colapso periódico. Sob todos esses sistemas, a moralidade era um código aplicável ao indivíduo, mas não à sociedade. A Sociedade foi colocada fora da lei moral, como a sua incorporação ou fonte ou intérprete exclusivo – e a inculcação de devoção auto-sacrificial ao dever social foi considerado como o principal objetivo da ética na existência terrena do homem.

Uma vez que não existe tal entidade como “sociedade”, já que a sociedade é apenas um número de homens individuais, isto significou, na prática, que os governantes da sociedade estavam isentos da lei moral, sujeita apenas aos rituais tradicionais, detendo o poder total e exigindo obediência cega – no princípio implícito de: “O bom é o que é bom para a sociedade (ou a tribo, a raça, a nação), e decretos do governante são sua voz na terra.”

Isto era verdade de todos os sistemas estatais, em todas as variantes da ética altruísta-coletivista, mística ou social. “O direito divino dos reis”, resume a teoria política do primeiro “Vox populi, vox Dei” do segundo. Como testemunha: a teocracia do Egito, com o faraó como um deus encarnado, a regra da maioria ilimitada ou democracia de Atenas, o estado de bem-estar executado pelos imperadores de Roma, a Inquisição da Idade Média, a monarquia absolutista da França, o estado de bem-estar da Prússia de Bismarck, as câmaras de gás da Alemanha nazista, o matadouro da União Soviética.

Todos estes sistemas políticos era expressões da ética altruísta-coletivista e sua característica comum é o fato de que a sociedade estava acima da lei moral, como um adorador caprichoso, onipotente, soberano. Assim, politicamente, todos estes sistemas eram variantes de uma sociedade amoral.

O resultado mais profundamente revolucionário dos Estados Unidos da América foi a subordinação da sociedade à lei moral.

O princípio dos direitos individuais do homem representou a extensão da moralidade no sistema social, como a limitação do poder do Estado, como a proteção do homem contra a força bruta do coletivo, como a subordinação do poder ao direito. Os Estados Unidos foram a primeira sociedade moral da história.

Todos os sistemas anteriores consideravam o homem como um meio de sacrifício para os objetivos dos outros, e da sociedade como um fim em si mesmo. Os Estados Unidos consideraram o homem como um fim em si mesmo, e a sociedade como um meio para a convivência pacífica, ordenada e voluntária de indivíduos. Todos os sistemas anteriores tinham considerado que a vida do homem pertence à sociedade, que a sociedade pode dispor dele da forma que quiser, e que qualquer liberdade que ele desfruta é seu apenas por favor, com a permissão da sociedade, que pode ser revogada a qualquer momento. Os Estados Unidos decidiu que a vida do homem é seu por direito (o que significa: por princípio moral e por sua natureza), que um direito é a propriedade de um indivíduo, que a sociedade como tal, não tem direitos, e que o único propósito moral de uma governo é a proteção dos direitos individuais.

Um “direito” é um princípio moral que define e sanciona a liberdade de ação de um homem em um contexto social. Existe apenas um direito fundamental (todos os outros são as suas consequências ou corolários): um direito do homem à sua própria vida. A vida é um processo de ações auto-geradas de auto-sustentação, o direito à vida significa o direito de exercer ações auto-geradas de auto-sustentação, o que significa: a liberdade de tomar todas as medidas exigidas pela natureza de forma racional sendo para o apoio, a promoção, a satisfação e o prazer de sua própria vida. (Esse é o significado do direito à vida, liberdade e a busca da felicidade.)

O conceito de “direito” se refere apenas à ação, especificamente, a liberdade de ação. Isso significa ausência de coerção física, coação ou interferência de outros homens. Assim, para cada indivíduo, um direito é a sanção moral de um positivo – de sua liberdade para agir em seu próprio julgamento, para seus próprios objetivos, por sua própria escolha voluntária. Quanto aos seus vizinhos, seus direitos não impõem obrigações a eles, exceto de um tipo negativo: de se abster de violar os seus direitos.

O direito à vida é a fonte de todos os direitos – e do direito de propriedade é a sua implementação. Sem direitos de propriedade, nenhum outro direito é possível. Já que o homem tem de sustentar a sua vida por seu próprio esforço, o homem que não tem direito ao produto do seu esforço não tem meios para sustentar a sua vida. O homem que produz, enquanto outros dispõe do seu produto, é um escravo.

Tenha em mente que o direito à propriedade é um direito de ação, como todos os outros: não é o direito a um objeto, mas a ação e as conseqüências de produzir ou ganhar esse objeto. Não é uma garantia de que um homem vai ganhar qualquer propriedade, mas apenas uma garantia de que ele terá sua propriedade se ganhá-lo. É o direito de adquirir, guardar, usar e dispor dos bens materiais.

O conceito de direitos individuais é tão nova na história da humanidade que a maioria dos homens não a compreenderam plenamente até hoje. De acordo com as duas teorias da ética, o místico ou o social, alguns homens afirmam que os direitos são um dom de Deus, outros, que os direitos são um dom da sociedade. Mas, na verdade, a fonte dos direitos é a natureza do homem.

A Declaração de Independência afirmou que “homens são dotados por seu Criador de certos direitos inalienáveis.” Se alguém acredita que o homem é produto de um Criador ou da natureza, a questão da origem do homem não altera o fato de que ele é uma entidade de um tipo específico de um ser racional que não pode funcionar com êxito sob coerção, e que os direitos são uma condição necessária para o seu modo particular de sobrevivência.

“A fonte dos direitos do homem não é a lei divina ou lei do Congresso, mas a lei da identidade. A é A e homem é homem. Os direitos são condições de existência exigido pela natureza do homem para sua própria sobrevivência. Se o homem deve viver na Terra, é direito dele usar sua mente, é direito agir em seu próprio livre julgamento, é direito trabalhar para os seus valores e manter o produto de seu trabalho. Se a vida na Terra é o seu propósito, ele tem o direito de viver como um ser racional: a natureza o proíbe do irracional. "(Atlas Shrugged.)

Violar os direitos do homem significa obrigá-lo a agir contra seu próprio julgamento, ou expropriar seus valores. Basicamente, só há uma maneira de fazê-lo: pelo uso de força física. Há dois potenciais violadores dos direitos do homem: os criminosos e o governo. A grande conquista dos Estados Unidos foi de estabelecer uma distinção entre esses dois, proibindo ao segundo a versão legalizada das atividades do primeiro.

A Declaração de Independência estabele o princípio de que “para assegurar esses direitos, governos são instituídos entre os homens.” Isso forneceu a única justificativa válida de um governo e definiu o seu único objetivo correto: para proteger os direitos do homem, protegendo-o da violência física.

Assim, a função do governo mudou do papel de governante para o papel servil. O governo foi instituído para proteger o homem dos criminosos – e a Constituição foi escrita para proteger o homem do governo. O Bill of Rights não era dirigida contra cidadãos particulares, mas contra o governo como uma declaração explícita de que os direitos individuais se sobressaem a qualquer poder público ou social.

O resultado foi o padrão de uma sociedade civilizada que, por breve espaço de cerca de cento e cinquenta anos, a América chegou perto de conquistar. Uma sociedade civilizada é aquela em que a força física é banida das relações humanas, em que o governo, agindo como um policial, pode usar a força apenas em retaliação e somente contra aqueles que iniciam seu uso.

Este foi o sentido essencial e intenção da filosofia política da América, implícita no princípio dos direitos individuais. Mas não foi formulado de forma explícita, nem totalmente aceita, nem consistentemente praticada.

A contradição interna da América foi a ética altruísta-coletivista. Altruísmo é incompatível com Liberdade, com o capitalismo e os direitos individuais. Não se pode combinar a busca da felicidade com o status moral de um animal de sacrifício.

Foi o conceito de direitos individuais que deu à luz a uma sociedade livre. Foi com a destruição de direitos individuais que a destruição da liberdade tinha de começar.

A tirania coletivista não se atreve a escravizar um país por um confisco dos seus valores, material ou moral. Tem que ser feito por um processo de corrupção interna. Assim como no reino material a pilhagem das riquezas de um país é feito inflacionando a moeda – então hoje se pode testemunhar o processo de inflação sendo aplicado à esfera de direitos. O processo envolve tamanho crescimento de recém promulgados “direitos” que as pessoas não percebem o fato de que o sentido do conceito está sendo revertido. Assim como dinheiro ruim acaba com o dinheiro bom, assim essa “máquina de imprimir direitos” nega os direitos autênticos.

Considere o fato curioso que nunca houve tal proliferação, em todo o mundo, de dois fenômenos contraditórios: de “direitos” novos e de campos de trabalho escravo.

O truque foi a troca do conceito de direitos da esfera política para a econômica.

A plataforma do Partido Democrata de 1960, resume a troca de forma ousada e explícita. Ela declara que uma Gestão Democrata “reafirmará o projeto econômico dos direitos que Franklin Roosevelt escreveu em nossa consciência nacional dezesseis anos atrás.”

Tenha claramente em mente o significado do conceito de “direitos” quando ler a lista que esta plataforma oferece:

“1. O direito a um trabalho útil e remunerado, em indústrias ou estabelecimentos comerciais ou fazendas ou minas do país.

“2. O direito de ganhar o suficiente para fornecer alimentação adequada, de vestuário e de recreação.

“3. O direito de cada agricultor para criar e vender seus produtos a um retorno que dará a ele e sua família uma vida decente.

“4. O direito de cada homem de negócios, grande e pequeno, de comercializar em uma atmosfera de liberdade em relação à concorrência desleal e da dominação de monopólios no país e no exterior.

“5. O direito de cada família a uma casa decente.

“6. O direito à assistência médica adequada e oportunidade de alcançar e gozar de boa saúde.

“7. O direito à proteção adequada para os temores econômicos da velhice, doença, acidentes e desemprego.

“8. O direito a uma boa educação.”

Uma pergunta simples adicionada a cada uma das oito cláusulas acima tornaria a questão clara: à custa de quem?

Postos de trabalho, alimentação, vestuário, recreação (!), casas, assistência médica, educação, etc, não crescem na natureza. Esses são valores feitos pelo homem – bens e serviços produzidos pelos homens. Quem vai fornecer isso a eles?

Se alguns homens têm garantia por direito aos produtos do trabalho dos outros, isso significa que os outros são privados de direitos e condenados ao trabalho escravo.

Qualquer alegação de “direito” de um homem, que implica na violação dos direitos do outro, não é e não pode ser um direito.

Nenhum homem pode ter o direito de impor uma obrigação não escolhida, um dever sem recompensa ou um direito de servidão involuntária a outro homem. Não pode existir qualquer coisa tal como “o direito de escravizar.”

Um direito não inclui a implementação material desse direito por outros homens; ele inclui apenas a liberdade de ganhar tal implementação por próprio esforço.

Observe-se, neste contexto, a precisão intelectual dos Pais Fundadores da América: eles falaram do direito à “busca pela felicidade”, não do direito à felicidade. Isso significa que um homem tem o direito de tomar as ações que considera necessário para atingir a sua felicidade, mas isso não significa que outros devem fazê-lo feliz.

“Consideramos estas verdades como evidentes por si mesmas, que todos os homens são criados iguais, que são dotados pelo Criador de certos direitos inalienáveis, que entre estes estão a Vida, Liberdade e a Busca pela Felicidade.” – Thomas Jefferson

O direito à vida significa que um homem tem o direito de apoiar a sua vida pelo seu próprio trabalho (em qualquer nível econômico, tão alto quanto a sua capacidade o levar), mas isso não significa que outros devem prestar-lhe as necessidades da vida.

O direito à propriedade significa que um homem tem o direito de tomar as medidas econômicas necessárias para ganhar sua propriedade, usá-lo e descartá-lo, mas isso não significa que outros devem fornecer-lhe essa propriedade.

O direito à liberdade de expressão significa que um homem tem o direito de expressar suas idéias, sem risco de supressão, interferência ou ação punitiva por parte do governo. Isso não significa que outros devem fornecer-lhe uma sala de aula, uma estação de rádio ou uma prensa de impressão para expressar suas idéias.

Qualquer empresa que envolve mais do que um homem, exige o consentimento voluntário de cada participante. Cada um deles tem o direito de tomar sua própria decisão, mas ninguém tem o direito de forçar a sua decisão sobre os outros.

Não há tal coisa como um “direito a um emprego”, existe apenas o direito de livre comércio, que é um direito do homem de ter um emprego se outro homem escolher contratá-lo. Não há direito a “uma casa”, apenas o direito de livre comércio: o direito de construir uma casa ou comprá-lo. Não existem direitos a um salário “justo” ou um preço “justo” se ninguém escolhe pagar por isso, contratar um homem ou comprar seu produto. Não há “direitos dos consumidores” ao leite, sapatos, filmes ou champanhe, se ninguém escolhe fabricar tais itens (existe apenas o direito de fabricá-los você mesmo). Não há “direitos” de grupos especiais, não há “direitos dos agricultores, dos trabalhadores, dos empresários, dos trabalhadores, dos empregadores, dos idosos, dos jovens, dos jovens.” Existem apenas os Direitos do Homem – direitos possuídos por cada homem individualmente e por todos os homens como indivíduos.

Os direitos de propriedade e o direito de livre comércio são os únicos “direitos econômicos” do homem (eles são, de fato, direitos políticos) – e não pode haver tal coisa como “um projeto de lei de direitos econômicos.” Mas observe que os defensores deste último tem feito tudo e destruíram o primeiro.

Lembre-se que os direitos são princípios morais que definem e protegem a liberdade de ação de um homem, mas não impõe obrigações aos demais. Os cidadãos não são uma ameaça para os direitos ou liberdades dos outros. Um cidadão que recorre à força física e viola os direitos dos outros é um criminoso e os homens têm proteção legal contra ele.

Criminosos são uma pequena minoria em qualquer época ou país. E o mal que fizeram à humanidade é infinitesimal quando comparado com os horrores – o derramamento de sangue, as guerras, as perseguições, a confiscação, as fomes, as escravidões, a destruição por atacado, perpetrados pelos governos da humanidade. Potencialmente, um governo é a ameaça mais perigosa para os direitos dos homems: ele detém um monopólio legal sobre o uso de força física contra vítimas legalmente desarmadas. Quando irrestrito e ilimitado pelos direitos individuais, um governo é o inimigo mortal dos homens. Não é como proteção contra ações privadas, mas contra as ações governamentais que o “Bill of Rights” foi escrito.

Agora observe o processo pelo qual essa proteção está sendo destruído.

O processo consiste em atribuir a cidadãos particulares as violações específicas constitucionalmente vedadas ao Governo (que cidadãos particulares não têm poder para cometer) e assim libertando o governo de todas as restrições. A troca está se tornando cada vez mais evidente no domínio da liberdade de expressão. Por anos, os coletivistas propagam a idéia de que a recusa de um indivíduo particular, de financiar um adversário é uma violação do direito do oponente da liberdade de expressão e um ato de “censura”.

É “censura”, dizem eles, se um jornal se recusa a empregar ou publicar escritores cujas idéias são diametralmente opostas à sua política.

É “censura”, dizem eles, se os empresários se recusam a anunciar numa revista que denuncia, os insulta e as mancha.

É “censura”, dizem eles, se um patrocinador de TV se opõe a algum atentado perpetrado em um programa que está financiamento, tais como o incidente de Alger Hiss sendo convidado a denunciar o ex-vice-presidente Nixon.

E depois há Newton N. Minow que declara: “Existe censura de popularidade, pelos anunciantes, pelas redes, pelas filiais que rejeitam a programação oferecida às suas áreas.” É o mesmo Sr. Minow que ameaça revogar a licença de qualquer estação que não seguir com sua opinião sobre a programação – e que afirma que isso não é censura.

Considere as implicações de tal tendência.

“Censura” é um termo que apenas diz respeito à ação governamental. Nenhuma ação privada é censura. Nenhum indivíduo particular ou agência pode silenciar um homem ou suprimir uma publicação; só o governo consegue fazer isso. A liberdade de expressão dos indivíduos particulares inclui o direito de não concordar, não ouvir e não financiar seus próprios antagonistas.

Mas de acordo com doutrinas como o projeto “econômico de direitos”, um indivíduo não tem o direito de dispor do seu próprio meio material através da orientação de suas próprias convicções – e deve entregar o seu dinheiro de forma indiscriminada a qualquer falador ou propagandista, que têm o “direito” à sua propriedade.

Isto significa que a capacidade de fornecer as ferramentas materiais para a expressão das idéias de um homem o priva do direito de ter a propriedade sobre qualquer idéia. Isso significa que um editor tem que publicar livros que considera inúteis, falsas ou más – que um patrocinador de TV tem que financiar comentadores que optam por afrontar suas convicções – que o proprietário de um jornal deve tornar suas páginas editoriais a qualquer jovem hooligan que clamar pela escravização da imprensa. Isso significa que um grupo de homens, adquire o “direito” à licença ilimitada – enquanto outro grupo é reduzido à irresponsabilidade desamparada.

Mas uma vez que é obviamente impossível fornecer qualquer reclamante com um emprego, um microfone ou uma coluna de jornal, quem irá determinar a “distribuição” dos “direitos econômicos” e selecionar os destinatários, quando o direito dos proprietários de escolha foi abolida? Bem, Sr. Minow indicou isso muito claramente.

E se você cometer o erro de pensar que isso se aplica apenas aos grandes proprietários, é melhor perceber que a teoria do “direito econômico” inclui o “direito” de cada aspirante a escritor, cada poeta jovem, cada compositor ruidoso e cada artista não-objetivo (que puxa saco de político) ao apoio financeiro que você não lhes deu quando não assistiu seus shows. O que mais é o significado do projeto para gastar o dinheiro dos seus impostos em arte subsidiada?

E enquanto as pessoas estão reclamando sobre os “direitos econômicos,” o conceito de direitos políticos, está desaparecendo. Esquece-se que o direito à liberdade de expressão significa a liberdade para defender pontos de vista e a encarar as possíveis consequências, incluindo desacordo com outros, oposição, impopularidade e falta de apoio. A função política do “direito à liberdade de expressão” é proteger as minorias dissidentes e impopulares da repressão violenta – não para garantir-lhes apoio, vantagens e recompensas de uma popularidade que não ganharam.

O “Bill of Rights” diz: "O Congresso não fará nenhuma lei … cerceando a liberdade de expressão ou de imprensa … " Ele não exige que os cidadãos privados ofereçam um microfone para o homem que defende a sua destruição, ou uma chave de acesso para o ladrão que quer roubá-los, ou uma faca para o assassino que quer cortar suas gargantas.

Tal é o estado de uma das questões mais cruciais de hoje: os direitos políticos versus “direitos econômicos.” É ou-ou. Um destrói o outro. Mas não existe, de fato, “direitos econômicos”, “direitos coletivos”, “direitos de interesse público.” A expressão “direitos individuais” é uma redundância: não há nenhum outro tipo de direitos e ninguém mais para os possuir.

Aqueles que defendem o capitalismo laissez-faire são os únicos defensores dos direitos do homem.

Playing with Dry Scaffold and Inherited Resources

Wed, 09 Sep 2009 11:40:37 PDT

There are several ways to start a new Rails project nowadays, specially since Rails brought project templates to the mix. On the other hand there are still lot’s of generators. So, today I want to just pinpoint some tips on this regard.

First of all, make sure you have all the usual suspects installed:

1	sudo gem install rspec rspec-rails josevalim-inherited_resources mislav-will_paginate justinfrench-formtastic thoughtbot-factory_girl haml ryanb-nifty_generators

One other is dry_scaffold from grimen. I’ve made a fork and added rspec support today. I think the 0.3.3 version should be generated soon from Github, then you will be able to install it like this:

1	sudo gem install akitaonrails-dry_scaffold

But you can also install it manually from the source:

1234	git clone git://github.com/akitaonrails/dry_scaffold.gitcd dry_scaffoldgem build dry_scaffold.gemspecsudo gem install dry_scaffold-0.3.3.gem

Now, create a normal Rails 2.3.x project and configure your config/environment.rb with:

config.gem 'haml'
config.gem 'will_paginate'
config.gem 'justinfrench-formtastic', :lib => 'formtastic', 
  :source => 'http://gems.github.com'
config.gem 'josevalim-inherited_resources', :lib => 'inherited_resources', 
  :source => 'http://gems.github.com'

And also add the following to your config/environments/test.rb:

12	config.gem 'rspec'config.gem 'rspec-rails'

In order to add Rspec support, create the initial Formtastic stylesheets and add a little bit of sugar to your layouts do the following:

123	./script/generate rspec./script/gererate formtastic_stylesheets./script/generate nifty_layout --haml

Notice that I am referring to Ryan Bates’ Nifty Generators. I really like it’s initial CSS and layout to start a new project instead of the default ‘blank’ theme. But that’s just me :-)

The excellent Formtastic will create your scaffolded views with a bit more of web semantics, so it’s highly recommended to use. To make it look pretty, add the following to your ‘app/views/layouts/application.html.haml’:

123	= stylesheet_link_tag 'application' = stylesheet_link_tag 'formtastic' = stylesheet_link_tag 'formtastic_changes'

Finally, you can start scaffolding some resources to get started, for example:

1	./script/generate dry_scaffold Post title:string body:text --rspec

If you don’t like fixtures you’d rather use Factory Girl instead doing this:

1	./script/generate dry_scaffold Post title:string body:text --rspec --fgirl

By default, it’s going to create thin controller with Inherited Resources and paginated with Will Paginate. The view templates will use HAML and Formtastic for a semantically rich form. It will create tests using the standard test/unit and fixtures, but I’d rather choose Rspec and Factory Girl.

It’s also going to generate a separated “_form” partial that both “new” and “edit” views will use, which is one of those things that you do all the time after a normal scaffold. The usage of HAML is not very common, but I would recommend everybody to at least try it for a while, it will grow on you quickly. And having well formatted HTML outputs is always nice.

The Dry Scaffold also supports generating just models (“./script/generate dry_model”). Read the documentation on the github project site to understand all the options.

With this, you should be good to go and start to rapidly prototype your next web application.

AkitaOnRails.com

[Off-Topic] Restaurantes e Tecnologia

Chatting with Adam Jacob

Chatting with Luke Kanies

[Tradução] Três Contextos Implícitos em Ruby

self

o chamado ‘klass’

Exemplos:

família eval

definição de constantes

[Tradução] Metaprogramação em Ruby: é tudo sobre Self

Rubistas.com.br

[Off-Topic] Obediência à Autoridade

Fred Brooks

[Off-Topic] Celulares e Aviões

[Off-Topic] O problema das credenciais

[Off-Topic] Saúde

Sit mens sana in corpore sano

Esclarecimento sobre “Perda de Peso”

[Rails Summit 2010] Commence Planning

[Rails Summit 2010] Iniciando o Planejamento

[Rails Summit 2009] Retrospectiva

Os Bastidores

Palestras

Minha Palestra

Comunidade

[Rails Summit 2009] ThoughtWorks pousa no Brasil

ThoughtWorks lands in Brazil

[Rails Summit 2009] Palestrante Arthur Zapparoli

Speaker Arthur Zapparoli

[Off-Topic] Windows and Unix: Promiscuidade

[Rails Summit 2009] Palestrante Nando Vieira

Speaker Nando Vieira

[Rails Summit 2009] Palestrante Ilya Grigorik

Speaker Ilya Grigorik

[Off-Topic] Procurar Raciocionar Faz Bem

[Rails Summit 2009] Palestrante Matt Aimonetti

Speaker Matt Aimonetti

[Rails Summit 2009] Palestrante Carlos Brando

Speaker Carlos Brando

[Off-Topic] Meu Backup Pessoal (Drobo/Time Capsule)

Disclaimer

Minha experiência até aqui

Conclusão

[Rails Summit 2009] Palestrante Bryan Liles

Speaker Bryan Liles

[Rails Summit 2009] Palestrante Leonardo Borges

Links

Speaker Leonardo Borges

Links

[Rails Summit 2009] O Trailer mais Esperado!

[Tradução] Os problemas do pensamento do Visual Studio (e outras IDEs)

Proliferação de APIs

IntelliSense

Código Gerado

Design Interativo

Até mais, Resource Script

Propriedades usadas Demais

Visual Studio Desmistificado

Os Prazeres Puros de Código Puro

[Rails Summit 2009] Teaser Trailer

[Off-Topic] A Argumentação através da Intimidação

[Off-Topic] Direitos do Homem

Capítulo 12 – Direitos do Homem

Playing with Dry Scaffold and Inherited Resources