rails.com.br

Atualmente estou envolvido em um projeto envolvendo módulos específicos em Ruby, Erlang e C. Ruby e Erlang são mais tranquilos, mas C tem a desagradável característica de deixar alguns códigos “meio” complicados de entender. Porém, um colega da Plano Bê me enviou um artigo que me ajudou muito e quero compartilhá-lo com vocês. O artigo [...]

Há uns 3 meses decidi que precisava de uma alternativa para repositórios privados no Git. Cancelei minha conta paga no Github e comecei a armazenar no Dropbox e no servidor do Simples Ideias. Não é que eu não goste do Github*. O único problema do Github é que os limites são muito baixos. O plano [...]

Já faz algum tempo que desenvolvi uma gem para imprimir o resultado dos meus testes de uma forma mais intuitiva, menos poluída e mais… colorida! Não sei bem porque, mas não divulguei muito essa gem na época. De qualquer forma, ai está: Para instalar é fácil, basta adicionar o seguinte código no seu arquivo Gemfile: [...]

If you follow my feeds, you probably saw that I’ve been tweaking my website since this weekend. So I decided to undertake yet another brain surgery and learn some new stuff in the process.

You can see the result at this staging subdomain. Let me know if you find any bugs. This is a heavily customized Enki blog adapted for Rails 3.1 beta running over Ruby 1.9.2 and Nginx/Passenger.

The very first step that I recommend is David Rice’s article on how to upgrade your Rails app to 3.1. It was invaluable in my process. First and foremost, the advice that applies to any Rails upgrade:

• Make sure your tests all pass and that you have good enough coverage to feel confident on heavy upgrades of this kind.
• git checkout -b rails3.1 – create a new branch where all the changes will be.

I’ll go over David’s bullet points on the upgrade process and you can compare my article with his to understand a few differences and how you can adapt those steps for your own projects.

Upgrade the Gemfile

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

source 'http://rubygems.org'

gem 'rake', '~> 0.8.7'
gem 'rails', :git => 'git://github.com/rails/rails.git'

# Rails 3.1 - Asset Pipeline
gem 'json'
gem 'sass'
gem 'uglifier'
gem "sprockets", :git => 'git://github.com/sstephenson/sprockets.git'

# Rails 3.1 - JavaScript
gem 'jquery-rails'

gem 'mysql2', '0.3.2'

gem 'will_paginate', :git => "git://github.com/akitaonrails/will_paginate.git", :branch => "rails3.1"
gem 'paperclip', :git => "git://github.com/thoughtbot/paperclip.git"
#gem 'newrelic_rpm', '~> 2.13'
gem 'acts-as-taggable-on', :git => "git://github.com/kuldarkrabbi/acts-as-taggable-on.git"
# ... more gems

# Bundle gems for the local environment. Make sure to
# put test-only gems in this group so their generators
# and rake tasks are available in development mode:
group :test, :development, :cucumber do
  # ... more gems
  # gem 'ruby-prof'
  platforms :mri_18 do
    gem "ruby-debug"
  end
end

group :production do
  platforms :mri_19 do
    gem 'psych', :require => 'psych'
    # Bundle a Javascript runtime, the recommended one is the V8 engine
    # that comes in The Ruby Racer
    gem 'execjs'
    gem 'therubyracer'
  end
end

In case you didn’t know about that, Rake received an upgrade after more than 2 years. We were all used to version “0.8.7” and then “0.9.0” was recently released. And lots of other gems and apps that depend on Rake broke badly, Rails included. You can read more about it in other blogs such as Yehuda’s explaining the situation and what to do. For now, remember to do either of these options:

1. declare the ‘0.8.7’ version in your Gemfile and make sure you don’t have 0.9.0 installed.
2. don’t mind the version but in a Rails app make sure you’re using bundle exec rake … to run the tasks.

Notice I had to use several gems directly from their github repositories. That’s because we’re too bleeding edge and Rails 3.1 deprecates things that breaks some gems. You will have to test one by one and research alternatives. Sometimes it’s as easy as pointing to their master branches. I just had one case where I had to make a fork for myself and add the fix (will_paginate). That’s why your test suite is important now.

I disabled new_relic because it broke as well but it was not important for this test, so it was easier to just comment it out.

For legacy reasons I was using Active Merchant as a plugin in vendor/plugins and I had to upgrade to the latest master branch version as well. But with added tweaks, in particular:

• vendor/plugins/active_merchant/lib/active_merchant.rb

1
2
3

#require 'active_support/core_ext/kernel/requires'
 require 'active_support/base64'
#require 'active_support/secure_random'

Ruby 1.8.7 and above comes with SecureRandom so Rails is deprecating it and kernel/requires is not available as well which requires another hack:

• vendor/plugins/active_merchant/lib/active_merchant/billing/integrations/action_view_helper.rb

1

#require_library_or_gem 'action_pack'

I had to make changes in my code and specs for acts-as-taggable-on but those are outside of the scope of this article. No hacks required, just implementing it as the current version documents it.

And finally, when you deploy it in a production environment I recommend you run bundle —path vendor/bundler to install all the gems locally to your application. That’s because otherwise Passenger seems to not be able to recognize git based dependencies within Bundler and it will break. If you install them all isolated inside your app, Passenger can find and load them without any problems.

Config File Changes

These are copied straight from David’s blog, you can safely just copy and paste within your app:

• config/boot.rb (replace all)

1
2
3
4
5
6

require 'rubygems'

# Set up gems listed in the Gemfile.
ENV['BUNDLE_GEMFILE']   = File.expand_path('../../Gemfile', __FILE__)

require 'bundler/setup' if File.exists?(ENV['BUNDLE_GEMFILE'])

• config/application.rb (append within the Application block)

1
2

# Enable the asset pipeline
config.assets.enabled = true

• config/environments/development.rb (remove or comment out the following line)

1

#config.action_view.debug_rjs             = true

• config/environments/production.rb (add these lines)

1
2
3

# Compress both stylesheets and JavaScripts
config.assets.js_compressor  = :uglifier
config.assets.css_compressor = :scss

Remember that you can change the Javascript compressor to YUI or something else, but I’d just stick to the defaults for now and tweak those later when your app is already up and running properly.

Move Assets

David instructs the following:

1
2
3
4

mkdir app/assets
git mv public/images app/assets/images
git mv public/javascripts app/assets/javascripts
git mv public/stylesheets app/assets/stylesheets

And then to judiciously using your tool of choice to search within all your front-end files (views, layouts, css, javascripts) and replace for the new locations:

1
2

find: /images/
replace: /assets/

Now I will add this: you are not required to move everything from the public folder to the new app/assets location, only those that you want or need to go through the Sprockets asset pipeline. For example, if you want to mix and compress all your CSS files than by all means move them to app/assets/stylesheets/. But let’s say you have just one print.css that is only available for media=“print”. You can maintain that at its original public location and link to it directly.

For those Stylesheets and Javascripts that you do want within the pipeline, you will need to create manifest files. The default manifest file names are:

• app/assets/javascripts/application.js

1
2
3
4
5
6
7
8
9

// This is a manifest file that'll be compiled into including all the files listed below.
// Add new JavaScript/Coffee code in separate files in this directory and they'll automatically
// be included in the compiled file accessible from http://example.com/assets/application.js
// It's not advisable to add code directly here, but if you do, it'll appear at the bottom of the
// the compiled file.
//
//= require jquery-1.3.2.min
//= require jquery-ui-1.7.2.min
//= require rails

• app/assets/stylesheets/application.css

1
2
3
4
5
6
7
8

/*
 * This is a manifest file that'll automatically include all the stylesheets available in this directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * the top of the compiled file, but it's generally better to create a new file per style scope.
 *= require akitaonrails/coderay
 *= require akitaonrails/style
 *= require akitaonrails/clearfix
*/

Most tutorials stop here. But my application has a separated Administration module with different stylesheets and javascripts, so I’ve create the following additional manifest files:

• app/assets/javascripts/admin/application.js

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// This is a manifest file that'll be compiled into including all the files listed below.
// Add new JavaScript/Coffee code in separate files in this directory and they'll automatically
// be included in the compiled file accessible from http://example.com/assets/application.js
// It's not advisable to add code directly here, but if you do, it'll appear at the bottom of the
// the compiled file.
//
//= require ../jquery-1.3.2.min
//= require ../jquery-ui-1.7.2.min
//= require ../jquery.livequery
//= require ../jquery.form
//= require ../jquery.easing.1.3
//= require ../humanmsg
//= require ./shortcut
//= require ./common
//= require ../rails

• app/assets/stylesheets/admin/application.css

1
2
3
4
5
6
7
8

/*
 * This is a manifest file that'll automatically include all the stylesheets available in this directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * the top of the compiled file, but it's generally better to create a new file per style scope.
 *= require ../formtastic
 *= require ../humanmsg
 *= require ./admin
*/

The paths are always relative to the application.[js css] file. If you have any problems, try to use “./” to point to the same folder you are. For the default manifests I didn’t have to resort to this trick but for some unknown reason I had to do that for the administration manifests.

But that is not all! Rails knows nothing about those other manifest files, so you have to declare them in your config/application.rb like this:

1
2

# Precompile additional assets (application.js, application.css, and all non-JS/CSS are already added)
config.assets.precompile += %w( admin/application.js admin/application.css )

Just so you can follow each path, my assets tree structure looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

 ~app/
   ~assets/
     +images/
     ~javascripts/
       ~admin/
         -actions.js
         -application.js
         -common.js
         -dashboard.js
         -edit-preview.js
         -pages.js
         -posts.js
        `-shortcut.js
       -application.js
       -common.js
       -humanmsg.js*
       -jquery-1.3.2.min.js*
       -jquery-ui-1.7.2.min.js
       -jquery.easing.1.3.js
       -jquery.form.js
       -jquery.jfeed.js
       -jquery.livequery.js
      `-rails.js
    `~stylesheets/
       ~admin/
         -admin.css
        `-application.css
       ~akitaonrails/
         -clearfix.css
         -coderay.css
         -print.css
         -style-ie.css*
         -style-ie6.css*
        `-style.css*
       -application.css
       -formtastic.css
       -formtastic_changes.css
       -humanmsg.css*
      `-iepngfix.htc*

Now, your layouts views can just point to the manifest file, like this:

• app/views/layouts/application.html.erb

1
2
3
4

<%= stylesheet_link_tag 'application' %>
<%= stylesheet_link_tag "akitaonrails/print", :media => "print" %>
...
<%= javascript_include_tag 'application' %>

• app/views/layouts/admin.html.erb

1
2

<%= javascript_include_tag "admin/application" %>
<%= stylesheet_link_tag    "admin/application" %>

Finally, in your production environment, don’t forget to statically generate your compiled assets with this Rake task:

1

RAILS_ENV=production bundle exec rake assets:precompile

It will create files such as these:

1

public/assets/application-2a8947193a591b79c885c52fbc6b01d3.css

And your final HTML output will be like this:

1

<link href="/assets/application-2a8947193a591b79c885c52fbc6b01d3.css" media="screen" rel="stylesheet" type="text/css" />

If one of your app/assets files change, the pre-compiled version will also change and hence the md5 hash changes too, making it safe to put cache systems such as Varnish in front of your application, because your users will not receive old versions of your assets.

Another important thing: I maintained my static images in the public/images folder so I can just keep the same urls inside the stylesheets, such as these:

• app/assets/stylesheets/akitaonrails/style.css

1

.main { background:url(/images/akitaonrails/header_bg.gif) no-repeat center top;}

If I wanted to keep the images at app/assets/images I would have to change the file to use ERB and add the following:

• app/assets/stylesheets/akitaonrails/style.css.erb

1

.main { background:url(<%= asset_path("akitaonrails/header_bg.gif")%>) no-repeat center top;}

That’s because in production even the images will be pre-compiled with their md5 hashes appended to their names. Check out this ticket to understand the issue and the best usage practice.

Conclusion

I had to tweak a few specs to make them pass because somethings changed (for example changing ActiveSupport::SecureRandom for just SecureRandom) but other than that the upgrade went pretty smoothly, nothing like upgrading from Rails 2.3 to Rails 3. Even then its not just a simple point release update of gems. Right now its pretty bleeding edge and several gems will break. The fixes are not complicated but unless there’s a feature you really need you should wait a few days after the official 3.1 release to let the gems maintainers add new versions as well.

On the other hand, there’s nothing wrong to anticipate the upgrade hassles and start now with the Edge version and at least check what breaks so you can monitor the required fixes being added to Github. The ideal situation is that you don’t need to point your Gemfile directly to the git repositories.

Again, benchmarks are not statements carved in stone but I just ran passenger-memory-stats and I got the following results:

1
2
3
4
5
6
7

     Passenger processes
PID    VMSize   Private  Name

30383  63.6 MB  34.9 MB  Rack: /var/webapps/akitaonrails
32433  68.5 MB  34.2 MB  Rack: /var/webapps/edge
### Processes: 7
### Total private dirty RSS: 88.97 MB

The Edge upgrade of the same application, running on the same patch version of Ruby 1.9.2, consumes a bit more memory even without the new_relic and ruby-prof gems that I’ve commented out.

I also ran a very simple Apache Bench cycle from my notebook, through my office wifi, into my production server (cross country, by the way, which is why times may not be reliable):

• ab -c 1 -n 10 http://www.akitaonrails.com/

1
2
3
4
5
6

Total transferred:      268650 bytes
HTML transferred:       261030 bytes
Requests per second:    1.27 [#/sec] (mean)
Time per request:       786.051 [ms] (mean)
Time per request:       786.051 [ms] (mean, across all concurrent requests)
Transfer rate:          33.38 [Kbytes/sec] received

• ab -c 1 -n 10 http://edge.akitaonrails.com/

1
2
3
4
5
6

Total transferred:      264410 bytes
HTML transferred:       257750 bytes
Requests per second:    0.70 [#/sec] (mean)
Time per request:       1433.169 [ms] (mean)
Time per request:       1433.169 [ms] (mean, across all concurrent requests)
Transfer rate:          18.02 [Kbytes/sec] received

So, Rails 3.1 Edge, right now seems to consume a little bit more memory than 3.0.5 (which is my current production version) and may probably be a bit slower. Again, take these numbers more as a curiosity for comparisons sake. Test in your own environment, because those behaviors can change considerably depending on how your application is built.

All in all, I like the new Assets Pipeline which is the largest visible change. It has created new grounds for evolution of the assets management. Be aware of the deprecations from Rails 3 to 3.1 because they will break a few gems. Overall, not a difficult upgrade, but as usual, do it with care.

There’s another article on Rails 3.1 deployment from Richard Taylor that I also recommend reading.

Update 05/29: Looks like I don’t have to hard code the IP address of rubygems.org because it seems like it always redirects to production.cf.rubygems.org. So pointing directly to it seems to do the trick.

Despite the current discussion around Rubygems maintenance, we can probably be assured that the current process of acquiring gems will remain largely unchanged.

On top of that we have at least 2 other variants to deal with, one being Bundler and the other being RVM Gemsets. The later is not being used so much because the former has more advantages.

The problem I face right now is: sometimes I have to reinstall several gems, several times. For example, if I have RVM with 3 different rubies, there will be the need to install Rails 3 times if I want to use it in every environment. If I have an isolated bundler vendor directory, or if I have a separated gemset for testing purposes, I will have to install several repeated gems again.

I don’t have any issues with disk space being wasted with so many copies, but one thing that does bother me is having to re-download everything everytime. Network speeds are not as fast as I wanted. There are several ways to make this less of a hassle, one being installing a full blown cached http proxy server and point the gem command there.

Another is to create your own small cache server just for rubygems. This is what Nando Vieira did with his Rubygems Proxy. I tweaked it and made a fork for myself with an added trick.

The original idea is: you change your .gemrc and your projects’ Gemfile to point the source to this new proxy application. Then whenever you run gem install or bundle, it would go through this new source. The proxy application is a very simple Rack app that checks if the files exists locally, otherwise it goes to the rubygems.org site, downloads and caches the file, so subsequent requests just fetch the file from disk.

The Hack

I changed this proxy app to request the file directly from production.cf.rubygems.org. It seems like “rubygems.org” merely redirects all gem requests to it. The reason for this hack is because now I can only add 127.0.0.1 rubygems.org to my /etc/hosts file and I don’t need to change the .gemrc or the Gemfile. Whenever something tries to install gems, it will hit my local proxy, which will cache the files as I wanted. Problem is, you lose access to the original website, but I personally don’t use it very much. Another hassle is if you publish gems, the gem push command will probably fail and another hack is probably required. I don’t publish gems too often so it’s not a problem for me. One can make a script to turn the /etc/hosts line on or off or just manually edit it whenever you need to publish a new version of your gem.

This should speed things up and I can see this being used in continuous integration servers, where false-positive alerts sometimes triggers because the bundle command wasn’t able to hit the rubygems.org server due to internal network instabilities, for example. But even for just my development environment, this should make things go smoother as the network will be hit only when the requested file is not available in the local cache.

The Fix?

Now, this is a big hack, I know this much. The correct thing to do is to change the RubyGems project itself to make it cache things correctly. The ideal thing would be for the gem command to fetch the online file and save it in a global repository, for example, /var/local/rubygems, then if you’re in Linux or Mac, the command could just symlink it. That way even if you have multiple rubies, with multiple gemsets and multiple projects using bundler, they would all point to the same original global directory. This would save not only network hits but also disk space, making RubyGems much more useful.

I am not familiar with the history of the RubyGems project, so I don’t know if this was attempted before and even if it is a good idea. If you’re more familiar with the project, let me know. And feedback if this hack is useful or not is welcome.

Fazia tempo que eu estava me devendo um redesign do meu blog. O antigo layout foi montado sobre um tema de wordpress que peguei no AskGraphics, mas há tempos que ele já estava ultrapassado. Meu problema é que não sou um bom designer. Um bom desenvolvedor de software sempre é só metade da solução, a outra metade necessariamente é um bom web designer.

Felizmente hoje existem muitas opções para pessoas como eu. Minha nova recomendação é o Dream Template. Hoje mesmo fiz minha assinatura para o plano Lifetime Premium Membership, que custa USD 194. Parece caro? De jeito nenhum. Isso não paga nem o período da manhã de atenção de um grande designer. Com esse plano, posso escolher qualquer um dos mais de 6 mil templates e usar em quaisquer sites pessoais ou comerciais que quiser. Pechincha!

Além disso esse plano dá acesso a outros sites como CSS Hub, IconObjects. Não vai me faltar elementos gráficos! De curiosidade, o template que escolhi foi o redppage

Outro serviço que comecei a usar é o Typekit. Alguns elementos do meu site estão usando a fonte Droid Sans porque é o que o template que escolhi usa. Ele já veio com suporte a Cufón, uma biblioteca Javascript que substitui elementos de texto no seu site por equivalentes com a fonte que você quiser sem precisar usar Flash. Se entendi direito, você faz o upload de sua fonte TTF no site deles e será gerado um Javascript com a representação dos glyphs dessa fonte (transformação binária em texto). Então, dinamicamente, o Cufón fará a troca dos elementos no seu site.

Porém a versão do Droid Sans que veio embutido no template não tinha letras acentuadas. Já que ia ter que mexer nisso resolvi mudar para o Typekit. A idéia é a mesma só que diferente do Cufón ele é um serviço online com mais facilidades. Você começa criando uma conta (tem versão Free) e ele lhe dá uma URL especial de Javascript que você coloca no seu site. A partir daí, no site deles, é possível escolher uma fonte dentre dezenas, especificar quais seletores de CSS usar para as substituições e ele automaticamente fará o que precisa a partir do Javascript especial customizado para seu domínio. É o que estou usando agora.

Finalmente, semana passada literalmente tivemos um grande “hype” sobre o produto chamado Hype. Ele é um editor de animações, uma aplicação nativa para Mac, que emula uma interface semelhante a de um Adobe Flash simplificado, com metáforas conhecidas como Scenes, Timelines, Keyframes. Só que ele exporta em HTML, CSS e Javascript! Desta forma é possível criar animações complexas usando sua interface WYSIWYG para criar animações complexas, substituindo completamente o uso de Flash para coisas desse tipo. Apenas como brincadeira eu animei o banner que tem agora no meu blog usando Hype. Coisa de um minuto.

A maioria dos desenvolvedores de software back-end não gosta muito de lidar com interfaces. Eu sou um deles. Porém evangelizamos que não se pode simplesmente fechar os olhos a isso e se tornar um ignorante. Eu não sou bom designer mas lido tranquilamente com Photoshop, Flash, HTML, CSS, etc. E se você ainda sequer sabe o que é um Profile de cor de imagens, deveria comprar os livros da Smashing Magazine. Eu mesmo quero me atualizar e comprei o maior bundle de 8 eBooks.

Enfim, com sites como a Smashing Magazine e seus associados, ferramentas como Hype, nós não-designers também podemos criar sites que não ferem os olhos. O que quero dizer é que não tem desculpa para fazer site feio. Não importa se seu código por baixo é lindo, todo testado, modularizado. No final, se ele for feio, ninguém vai dar atenção. Essa é a lei número 1 do consumidor: se a embalagem for feita, eu não compro o produto, mesmo que o produto dentro da caixa feia seja a melhor coisa do mundo.

Muitas pessoas talvez não tenham entendido minha posição no artigo anterior Mea Culpa: Organizações Democráticas não Funcionam. Recomendo que tentem ler o artigo anterior com calma para entender o conceito correto de Democracia. Mas para complementar devo explicar. O maior problema que todos tem é acreditar que “democracia” é a única e melhor forma de governar ou, mais genericamente, decidir qualquer coisa porque “a maioria”, “o povo”, “as massas” sempre tem razão e o que foi decidido coletivamente deve prevalecer. E este é o maior erro de todos os tempos.

Resumindo o que disse antes: Liberdade é importante, defender a liberdade é importante, e a liberdade mais importante que deve ser defendida é do indivíduo. A maioria jamais deve tiranizar a minoria. E a menor minoria sempre é o indivíduo. Se um indivíduo é privado de sua liberdade, não existe liberdade para ninguém.

Isso dito, num estado de liberdade, todos tem direito a formular e expressar suas opiniões. A confusão é quando uma opinião é proferida por uma “maioria”. Democraticamente falando, essa “opinião” parece ter muito valor. E isso é outro grande erro.

Novamente, vamos definir:

• Opinião: é uma visão ou julgamento formado sobre alguma coisa, não necessariamente baseado em fato ou conhecimento.

• Verdadeiro: de acordo com fato ou realidade. Apurado, exato. Real.

Opinião não é fato nem verdade.

E opinião de uma maioria jamais será automaticamente uma verdade. Qualquer opinião de uma maioria jamais será maior do que a verdade comprovada proferida por um único indivíduo, não importa o volume dessa maioria.

Isso é importante. Justamente por isso eu disse que a melhor forma de pensar em organizações não é de forma “puramente” democrática. No nosso nicho particular de desenvolvimento de software, muitos assumem que agilistas e métodos ágeis são “democráticas”. Se você ler na própria Wikipedia sobre Scrum, teremos esta definição para “equipe”:

Uma Equipe é responsável por entregar o produto. Uma Equipe é tipicamente formada por 5 a 9 pessoas com capacidades cross-funcionais que realizam o trabalho propriamente dito (análise, design, desenvolvimento, teste, comunicação técnica, documentação, etc). É recomendado que a Equipe seja auto-organizada e auto-liderada, mas normalmente trabalhe com alguma forma de projeto ou gerenciamento de equipe.

Em nenhum momento diz que a Equipe pode ser anárquica. Mas as pessoas lêem de forma errada o conceito de auto-organização como “fazemos como queremos”. E isso está completamente errado.

É o mesmo problema de um sistema de governo puramente democrático. A maioria pode de fato decidir entre si a implementação de alguma lei, ou princípio, ou verdade. Por exemplo, um princípio inviolável e indiscutível é que um indivíduo deve conseguir manter para si os produtos do seu próprio trabalho. A comunidade pode decidir, democraticamente, se a implementação será na forma de um corpo policial cujo custo será dividido igualmente entre todos, por exemplo.

Esse é o ponto que falta quando falamos em organizações ou equipes ágeis. As equipes podem decidir democraticamente como executar a implementação, porém todos precisam entender que existem princípios invioláveis que limitam quais decisões essa “democracia” pode tomar. Voto ignorante em grande volume, para mim, significa apenas um grande volume de ignorância. Quer definir o que é verdade? Estude, pesquise, demonstre, prove. Basta um único indivíduo com a demonstração correta para bater destroçar qualquer opinião de qualquer maioria, mas nunca o oposto.

Por exemplo, o objetivo de uma empresa é obter a maior quantidade de lucro possível. Não há outro objetivo em um trabalho que não seja ter lucro. Portanto, não importa se você faz o software mais bem feito – na sua opinião pessoal, diga-se de passagem, o que não torna isso um fato – se ele gera prejuízo em vez de lucro.

Lucro é uma premissa, mas não é a única. Lembre-se da definição de “Equipe” anterior. Uma equipe deve ser “responsável”, ou seja, ela deve se comprometer em entregar um projeto da forma como o cliente espera, incluindo o gerenciamento dessa expectativa (que vou explicar em mais detalhes em outro artigo).

Um projeto encomendado a uma equipe não pertence à equipe, pertence a quem está pagando por ele. Uma equipe dita ágil, que se responsabiliza por um projeto, não está se responsabilizando meramente em codificar o produto pedido, mas sim em cuidar das expectativas do cliente, do começo ao fim.

Mais ainda, o objetivo de um projeto não é fazer um software, é atingir um resultado ao cliente. Ou seja, ao cliente não importa se um software usa técnicas X ou Y que aumentam sua qualidade – qualidade é uma característica trivial já esperada por quem encomenda – o valor do cliente vem do resultado obtido por esse software. Ou seja, o objetivo de um projeto de e-commerce, por exemplo, não é no software de e-commerce em si, mas nas vendas geradas. Se fizer o software mais avançado do mundo, com as melhores arquiteturas, melhores tecnologias, mas que nunca vendeu um único produto, ele não vale nada. Já um e-commerce feito com as piores tecnologias, com todas as gambiarras já documentadas, mas que efetivamente ajudou a gerar 1 milhão de vendas diretas ao seu cliente, é infinitamente superior, inquestionavelmente.

Um desenvolvedor de software deve prezar por seu trabalho técnico. Isso é ótimo e deve continuar. Um arquiteto de sistemas preza por sua análise e arquitetura. Também nenhum problema. Um agilista preza por seus processos e rituais. Cada profissional deve realmente tentar sempre o melhor no que faz. Porém, nenhuma das atividade específicas de cada um é mais importante do que o do outro e nenhuma delas é um fim em si próprio. Ou seja, um desenvolvedor de software preocupado única e exclusivamente no seu código, não importa a qualquer custo, é um péssimo profissional.

E aqui entra a diferença entre um profissional e um amador: ética profissional.

O profissional carrega responsabilidade moral adicional sobre a população em geral e a sociedade. Isso porque profissionais são capazes de realizar e agir em decisões informadas em situações onde o público em geral não conseguiria, porque não tiveram treinamento relevante. Por exemplo, uma pessoa normal do público não poderia ser responsável por falhar em agir em salvar a vítima de um acidente de carro porque ele não conseguiu realizar uma traqueostomia de emergência. Isso é porque ele não tinha conhecimento relevante. Em contraste, um médico totalmente treinado (com o equipamento correto) seria capaz de realizar o diagnóstico correto e realizar o procedimento e nós julgaríamos como incorreto se ele ficasse parado sem ajudar nessa situação. Você não pode ser julgado culpado por não realizar algo que não tem capacidade de fazer. Éticas são regras e valores usados em um ambiente profissional.

A tradição da medicina, por exemplo, está na herança do Juramento de Hipócrates, por milênios sendo atualizada e a seguinte a versão moderna:

• Juro cumprir, o melhor que minha habilidade permitir, esta aliança:
• Respeitarei os ganhos científicos duramente conquistados por aqueles médicos cujos passos eu sigo, e compartilharei tal conhecimento com prazer como é meu àqueles que seguirão.
• Aplicarei, para benefício do doente, todas as medidas requeridas, evitando as facas de dois gumes do tratamento excessivo e niilismo terapêutico.
• Lembrarei que existe arte à medicina assim como ciência, e que o calor, simpatia e entendimento pode superar o bisturi do cirurgião ou a droga do químico.
• Não me envergonharei em dizer “Eu não sei” nem falharei em chamar meus colegas quando as capacidades de outros são necessários para o recuperamento do paciente.
• Respeitarei a privacidade de meus pacientes, pois seus problemas não são reveladas para mim para que o mundo saiba. Mais especificamente devo tratar com cuidado em casos de vida ou morte. Se me é dada a tarefa de salvar uma vida, muitos agradecimentos. Mas também pode estar dentro do meu poder retirar uma vida; esta responsabilidade incrível deve ser encarada com grande humildade e consciência da minha própria fragilidade. Acima de tudo, eu não devo brincar com Deus.
• Me lembrarei que eu não trato um gráfico de febre ou um câncer em crescimento, mas um humano doente, cuja doença pode afetar a família e estabilidade econômica da pessoa. Minha responsabilidade inclui esses problemas relacionados, para tratar adequadamente o doente.
• Previnirei doença sempre que puder, pois prevenção é preferível à cura.
• Me lembrarei que continuo sendo um membro da sociedade, com obrigações especiais com todos os meus companheiros humanos, aqueles sãos de mente e corpo, assim como os enfermos.
• Se eu não violar este juramento, que eu possa desfrutar a vida e a arte, respeitado enquanto viver e lembrado com afeição após. Que eu aja somente para preservar as finas tradições do meu chamado e que eu aprecie por muito tempo a experiência de curar aqueles que procuram minha ajuda.

Não é nem de longe uma versão “definitiva”, mas vou aproveitar para adaptar de forma muito próxima ao Juramento de Hipócrates o que poderia ser um rascunho de juramento para programadores, apenas para deixar clara a idéia de que todo profissional tem responsabilidades maiores do que meramente sua atividade geral de trabalho:

• Juro cumprir, o melhor que minha habilidade permitir, esta aliança:
• Respeitarei os ganhos científicos duramente conquistados por aqueles programadores cujos passos eu sigo, e compartilharei tal conhecimento com prazer como é meu àqueles que seguirão.
• Aplicarei, para benefício do cliente, todas as medidas requeridas, evitando as facas de dois gumes da aplicação excessiva de tecnologias ou preconceito por marcas ou tecnologias que desconheço.
• Lembrarei que existe arte no desenvolvimento de software assim como ciência, e que o calor, simpatia e entendimento pode superar o código do programador ou a diagrama do analista.
• Não me envergonharei em dizer “Eu não sei” nem falharei em chamar meus colegas quando as capacidades de outros são necessários para o benefício do projeto do cliente.
• Respeitarei a privacidade de meus clientes, pois seus problemas não são reveladas para mim para que o mundo saiba. Mais especificamente devo tratar com cuidado projetos de minha empresa ou meus clientes. Se me é dada a tarefa de entregar um projeto, muitos agradecimentos. Mas também pode estar dentro do meu poder recuperar um projeto fracassando; esta responsabilidade incrível deve ser encarada com grande humildade e consciência da minha própria fragilidade. Acima de tudo, eu não devo brincar em serviço.
• Me lembrarei que eu não lido com um arquivo de código ou uma ferramenta de edição, mas um projeto, cuja resultado pode afetar a estabilidade econômica do cliente, dos funcionários da empresa do cliente e suas famílias. Minha responsabilidade inclui esses problemas relacionados, para desenvolver adequadamente o projeto.
• Previnirei bugs e problemas técnicos sempre que puder, pois prevenção é preferível à correção.
• Me lembrarei que continuo sendo um membro da sociedade, com obrigações especiais com todos os tipos projetos, aqueles que eu posso começar do zero do meu jeito, ou os que herdar com estilo de outros.
• Se eu não violar este juramento, que eu possa desfrutar a vida e a arte, respeitado enquanto viver e lembrado com afeição após. Que eu aja somente para preservar as finas tradições do meu chamado e que eu aprecie por muito tempo a experiência de desenvolver projetos àqueles que procuram minha ajuda.

Meu ponto com esse texto é relembrar o seguinte:

• parem de usar “democracia” com conotações populistas. Não é meramente a “equipe” que deve ser “protegida” ou “beneficiada”, mas sim o resultado do cliente e seus projetos. Nunca se esqueçam disso.
• certos princípios são invioláveis e não estão abertos à votação, objetivos de negócio numa ponta, ética profissional na outra.
• todos tem direito a ter e expressar opiniões pessoais, mas opiniões são apenas isso: opiniões, não fatos. E votos jamais transformarão opiniões em verdades. 2 + 2 será 4 não importa quantas pessoas votem dizendo que é 5.
• demonstrem um pouco de respeito e dignidade à sua profissão. Você trabalha, de fato, em benefício próprio, mas nunca causando prejuízo aos outros. Vou repetir isso ad nauseum: você só tem trabalho porque há alguém disposto a pagar por ela, seja ético, seja profissional.

Sinceramente, me incomoda muito pensar num mundo onde uma maioria ignorante pode decidir, por votação, que a terra é chata, que simpatias funcionam, que um funcionário “merece” um salário compulsoriamente maior do que uma empresa tem condições de pagar, que o divertimento de um “profissional” está acima de suas responsabilidades. Jurem a si mesmos – não a mim ou a um terceiro qualquer – que serão profissionais, ou desistam de trabalhar na mesma área que nós para parar de nos envergonhar, nós que levamos isso a sério.

Acabei de liberar o e-book O que mudou no Ruby 1.9 gratuitamente. Este e-book, lançado originalmente em 2009, vendeu mais de 200 cópias. Se puder, compre o e-book Ruby Metaprogramming e aprenda a utilizar todo o poder da metaprogramação do Ruby em um guia de 60 páginas, recheado de exemplos práticos sobre Object Model e [...]

Se você não pode participar do workshop de Ruby Metaprogramming do HOWTO, não tem problema! Agora você pode comprar o e-book utilizado no workshop por apenas R$15,00. O PDF é formatado para a leitura em computadores, então você não vai precisar ficar rolando a página para ver aquelas últimas linhas. Além disso, você receberá um [...]

Quem está me acompanhando nos últimos 4 anos nas minhas discussões sobre formas de gerenciamento e de organização de empresas vai se lembrar que eu muitas vezes não só flertei como procurei maneiras de tentar defender um tipo de organização “democrática”. Esse conceito sempre foi incompleto e eu imaginava que mais cedo ou mais tarde a equação iria se fechar. Em vez disso estou retornando ao zero e redefinindo esses conceitos. A primeira coisa que eu preciso corrigir é o uso da palavra “Democracia”. Essa palavra não condiz com o tipo de organização que eu descrevo.

Minha linha de pensamento sempre é baseada em Evolucionismo Darwinista. É a única forma onde Caos consegue tender a uma certa Ordem através de auto-organização. Esse processo envolve diversos mecanismos e é onde já palestrei sobre Redes de Livre Escala, sobre Sistemas Complexos Adaptativos, e como tudo isso leva a processos, metodologias, incluindo o tão discutido Scrum. Essa linha de estudo – que você pode acompanhar nos meus blogs e palestras dos últimos 3 anos – passa superficialmente por temas de biologia, sociologia, psicologia, filosofia, física, matemática. Em última instância me parecia que o caminho mais coerente era em torno do que hoje em dia ficou conhecido como Organizações Democráticas, especialmente por causa de cases famosos como a Semco, de Ricardo Semler e aspectos de democracia na organização que podem ser observadas em empresas como Southwest Airlines, Dreamhost, Groupon, Zappos.

Porém, eu mesmo fui vítima daquilo que sempre critico: um grupo de evidências positivas sobre um modelo, por melhor que pareçam ser, nunca provam o modelo! Concluir baseado apenas em evidências positivas é o mesmo que cargo cult. Portanto, a primeira coisa que devo corrigir é: o tipo de organização que descrevo e defendo não tem a ver com “Democracia”, portanto na minha concepção, o termo “Organizações Democráticas” é um erro.

Democracia vs República

Ainda bem que nosso país se chama “República Federativa do Brasil”. Atualmente não conheço quem fale mal da palavra “democracia”. Não vou pretender dar uma aula de política mesmo porque eu estudei quase nada de ciências-políticas. Sem me ater a todas as ramificações, quero descer primeiro às mínimas definições do termo e idéias originais. Novamente como tenho repetido, descendo às “definições”.

Eu não defendo o dono deste site nem todas as suas idéias, mas o texto que ele escreveu serve meus propósitos portanto resolvi traduzí-lo diretamente. Para o original acesse este artigo de Gary McLeod. Se procurar no Google por “democracy vs republic” vocês encontrarão centenas de artigos explicando em mais detalhes as diferenças. Mas por enquanto este serve. Segue a tradução:

Governo pela Lei vs Governo pela Maioria

Logo depois de completar a assinatura da Constituição, em resposta à pergunta de uma mulher sobre o tipo de governo que os Fundadores criaram, Benjamin Franklin disse, “Uma República, se vocês conseguirem mantê-la.”

Não só falhamos em mantê-la, mas a maioria nem sabe o que é isso.

Uma República é um governo representatitivo dirigido pela lei (a Constituição). Uma Democracia é um governo direto (nota do Akita: sim, existe democracia representativa, mas como disse não vou descer todas as ramificações) dirigido pela maioria (governo de máfia). Uma República reconhece os direitos inalienáveis dos indivíduos enquanto democracias somente se preocupam com os desejos e necessidades do grupo (o bem público). Criar leis é um processo deliberativo lento na nossa República Constitucional, requerendo a aprovação de 3 ramificações do governo, a Suprema Corte e juristas individuais (júri de nulificação). Criar leis em nossa democracia sem lei acontece rapidamente requerendo aprovação de um capricho da maioria como determinada por enquetes ou referendums. Um bom exemplo de democracia em ação é linchamento.

Democracias sempre se auto-destróem quando a maioria não-produtiva se dá conta que pode votar para ganho própria a prejuízo da minoria produtiva elegendo o candidato que promete mais benefícios do tesouro público. Para manter seu poder, esses candidatos devem adotar impostos cada vez maiores e maior gastança para satisfazer os desejos sempre crescentes da maioria. À medida que impostos crescem, o incentivo à produção decresce, fazendo com que os poucos que produziam desistam e se juntem aos não-produtivos. Quando não houver mais produtores suficientes para financiar as funções legítimas do governo e programas socialistas, a democracia entrará em colapso, sempre para ser seguido por uma ditadura.

Mesmo que quase todos os políticos, professores, jornalistas e cidadãos acreditem que nossos Fundadores tenham criado uma democracia, isso não é verdade em absoluto. Os Fundadores sabiam muito bem das diferenças entre uma República e uma Democracia e eles repetidamente e enfaticamente diziam que eles fundaram uma República.

Artigo IV Seção 4, da Constituição “garante a cada estado nesta união uma forma de governo Republicana” … Reciprocamente, a palavra Democracia não é mencionada nem mesmo uma vez na Constituição. Madison nos avisou dos perigos da democracia com estas palavras,

“Democracias sempre foram espetáculos de turbulência e contenção; sempre foram incompatíveis com segurança pessoal ou os direitos de propriedade; e em geral tiveram tempo de vida tão curto quanto tiveram mortes violentas …”,

“Nós podemos definir uma república como sendo … um governo que deriva seus poderes diretamente ou indiretamente do grande corpo de pessoas, e é administrado por pessoas que mantém seus escritórios durante bons tempos por um período limitado, ou durante bom comportamento. É essencial para tal governo que ele seja derivado de um grande corpo da sociedade, não de uma proporção inconsiderável de uma classe favorecida por ele; caso contrário um punhado de nobres tiranos, exercitando sua opressão por uma delegação de seu poder, pode aspirar serem republicanos e clamarem por seu governo como tendo o título honroso de república” James Madison, Federalist No. 10, (1787)

“Um homem sábio não abandonará seu direito à mercê da sorte, nem deseja que ela prevaleça pelo poder da maioria. Há pouca virtude nas ações de massas de homens.” Henry David Thoreau (1817-1862)

Nossos manuais de treinamento militar contém as definições corretas de Democracia e República. O seguinte vem dos Manuais de Treinamento No. 2000-25 publicados pelo Departamento de Guerra, 30 de Novembro de 1928.

DEMOCRACIA:

• Um governo das massas.
• Autoridade derivada através da reunião em massa ou qualquer outra forma de expressão “direta”.
• Resulta em mafiocracia.
• Atitude sobre propriedade é comunista – negando direito à propriedade.
• Atitude sobre leis é que o desejo da maioria deve regular, seja baseada em deliberação ou governado por paixão, preconceito e impulso, sem limitações ou consideração às consequências.
• Resulta em demagocia, licença, agitação, descontentamento, anarquia.

REPÚBLICA:

• Autoridade é derivada através das pessoas elegendo oficiais públicos melhor qualificados para representá-los.
• Atitude sobre a lei é a administração da justiça de acordo com princípios fixos e evidência estabelecida, com consideração estrita às consequências.
• Um número maior de cidadãos e extensão de território podem ser adicionadas ao seu compasso.
• Evita os perigosos extremos de tirania ou mafiocracia.
• Resulta em estadismo, liberdade, razão, justiça, contentamento e progresso.
• É a “forma padrão” de governo pelo mundo.

Os manuais contendo tais definições foram destruídos sem explicação na mesma época que o presidente Franklin D. Roosevelt (F.D.R) tornou ilegal a propriedade privada de nosso dinheiro legítico (Moedas de Outro cunhadas). Logo depois que as pessoas entregaram suas moedas de outro de $20, o preço subiu de $20 por onça para $35 por onça. Quase do dia para a noite, F.D.R, o mais popular presidente deste século (eleito 4 vezes) saqueou quase metade da riqueza desta nação, enquanto convencia as pessoas que era para seu próprio bem. Muitas das políticas do F.D.R. foram sugeridas pelo seu braço direito, Harry Hopkins, que dizia,

“Impostos e Impostos, Gastos e Gastos, Eleger e Eleger, porque as pessoas são burras demais para saber a diferença”

Não Pode Ser Democracia

Se vocês pesquisarem pelo menos os artigos do Wikipedia sobre Democracia e República verão que o assunto é bem mais complexo do que isso.

O que eu mais admiro quando falamos sobre os Pais Fundadores dos Estados Unidos era essa clareza filosófica e política que os levou a descrever uma República baseada em Direitos Individuais inalienáveis, gerando fundações sólidas como a Declaração de Independência e a Carta de Direitos. Claro, não estou dizendo que eles eram pessoas perfeitas, todos tinham mil defeitos, mas não se atenham a isso (afinal isso seria Falácia do Homem de Palha).

As ditas Organizações Democráticas falham justamente nesse ponto, em sua fundação. Ela simplesmente não existe. E pior, é incompatível com a Constituição do ponto de vista filosófico.

Não há um documento “oficial” que descreva seus princípios, portanto vou pegar emprestado a lista de princípios descrita pela WorldBlu, uma organização que tenta difundir a idéia de Organizações Democráticas pelo mundo. Leia na página deles para mais detalhes, mas resumidamente, temos os seguintes princípios:

1. Propósito e Visão – normal, qualquer empresa precisa ter isso claro, qual seu core business, e para que ela existe.
2. Transparência – há controvérsias, nem tudo pode ser aberto, inclusive algumas coisas realmente são legalmente protegidas.
3. Diálogo + Ouvir – concordo, o conceito é válido, e contra autoritarismo de cima-pra-baixo
4. Igualdade + Dignidade – difícil definir, algumas diferenças de tratamento são mais culturais do que mandatórias
5. “Accountability” – é difícil de traduzir em português mas é algo como “Responsabilidade”, mas nesse conceito é mais sobre melhor definição de quem é responsável por o quê.
6. Individual + Coletivo Р̩ aqui que o conceito todo come̤a a desmoronar.
7. Escolha – implementável, mas dentro de limites.
8. Integridade – menciona “moralmente” e “eticamente” correto. isso é um problema.
9. Descentraliza̤̣o Рem vez de centraliza̤̣o, sempre sou a favor disso, mas dentro de limites.
10. Reflexão + Avaliação – um “toque” de modelo Hansei+Kaizen da Toyota.

Os dois últimos pontos, Descentralização, Reflexão e Auto-Avaliação são os únicos que eu consideraria como “princípios”. Se lerem meus artigos linkados na introdução deste texto entenderão melhor esses princípios.

Meu problema com esses princípios: eles são retóricos e por isso não servem como princípios. Simplesmente dizer, “tem que ser transparente” é retórico. Eu posso lhes dizer que nunca disse uma mentira, e quem vai me desprovar?

O mesmo vale para “diálogo”, “dignidade”, são boas retóricas, mas são descrições de conduta, ou seja, são o processo e não a fundação. Elas não lidam com o real princípio: “Por que eu devo agir dessa forma?”

E isso recai no ponto da “Integridade”. Sobre fazer o que é moralmente e eticamente certo. E quem define o que é moralmente e eticamente certo? Sem uma filosofia por trás, isso está indefinido e aberto à interpretação, pois novamente não há um princípio objetivo, não ambíguo, por trás.

Propriedade Privada

Finalmente, os pontos sobre “Individual + Coletivo” e “Escolha”. São os pontos onde diretamente se trata sobre “Democracia”. Esses dois pontos quebram completamente qualquer outro. Democracia e Coletivo não são bons princípios. Qualquer sistema onde a maioria pode esmagar a minoria, e a minoria não tem direitos de propriedade objetivos, definidos, não funciona por definição.

E “direitos”, entenda-se, não é qualquer coisa. Como por exemplo, “direito a bônus”, “direito a mais horas de descanso por semana” . Tudo precisa recair no problema fundamental de qualquer organização: “E quem paga a conta?” Se para um indivíduo ter um direito, outro indivíduo precisa trabalhar de graça, isso define escravidão e, por definição, não pode ser um direito. Leia meu artigo sobre Direitos do Homem para entender isso.

Mais do que isso: “Transparência” no sentido de acesso irrestrito a todos os dados da empresa, Escolha sobre todos os assuntos relevantes da empresa, nunca devem ser direitos automáticos dos funcionários.

Vamos à fundação disso tudo: toda empresa e organização é uma propriedade privada de seu dono, sócios ou acionistas. Ela não pertence aos funcionários a menos que eles também sejam acionistas da empresa, por exemplo, via programa de stock options ou coisa do tipo.

Funcionários são indivíduos que estão trocando suas capacidades e horas de trabalho voluntário, numa negociação voluntária com a empresa por um valor chamado “salário”. É uma negociação justa, voluntária, para mútuo benefício. O direito do funcionário termina onde termina o que está escrito em seu contrato de trabalho, devidamente assinado. Não há o que ser “reinvindicado”.

Quer mais acesso a informações sigilosas da empresa e mais acesso nas decisões estratégicas? Mereça! Faça por merecer! Não ache que ela deve cair no seu colo de forma automática. Mostre um bom trabalho, mostre um excelente resultado, e demonstre ter capacidade para tomar decisões e só então ganhe o merecimento de fazer parte. O princípio de uma organização do ponto de vista de seus funcionários sempre deve ser a meritocracia.

Mas e quanto às várias empresas que são “evidências” positivas de que “organizações democráticas” funcionam?

Eis aqui o ponto-chave de todo este artigo: esses cases de Organizações Democráticas não são necessariamente Democráticas. Pelo menos não como as pessoas imaginam que deveria ser.

Na realidade, se vocês lerem meus artigos sobre grupos de animais, caos levando à ordem, auto-organização, faz todo o sentido dentro de limites. Ou seja, não faz sentido uma organização tentar controlar até mesmo a cor da meia que cada funcionário usa. Isso não faz sentido, não é eficiente, não é produtivo. A “maneira” como equipes trabalham, que horas, com que ferramentas, com quais códigos de conduta, etc é algo que a própria equipe pode decidir. Mas entenda que para chegar nesse ponto, as metas da empresa, onde ela quer chegar, o que quer produzir, como quer entrar no mercado, e todas essas outras decisões, já foram tomadas.

O que as equipes vão “democraticamente” decidir, é como essa estratégia será implementada. Ou seja, o “alto-escalão” continua existindo, a empresa ainda pertence a seus donos e eles fazem com ela o que quiserem, e a estratégia chega pronta. O que fica a cargo dos funcionários é a tática, a implementação. Esse é o caminho natural para as organizações. Se quiserem chamar isso de “democrático”, tudo bem, prefiro não dar nenhum nome ou etiqueta e considerar que isso é apenas mais um passo evolucionário de “Organizações”.

Ou seja, deixar a “forma de implementar a estratégia” à escolha dos funcionários que vão implementá-la é só mais uma maneira que parece eficiente de gerenciar um negócio. Não vale necessariamente para todos os negócios. E nas empresas consideradas cases acredito que vamos encontrar mais evidências que elas não são “organizações democracias” mas sim organizações que empregaram meios mais eficientes de produção. É como o Toyota Production System (TPS, ou Lean para nós) empregado pela Toyota. Ela não aparece listada como “organização democrática” nas listas mais populares, e provavelmente não se encaixa nos princípios da WorldBlu, mas ela emprega de fato táticas “democráticas”, ou “participativas” na implementação da produção. E esse é o objetivo real.

E não se preocupem, também não acho que o termo correto deveria ser “Organizações Republicanas” – só porque falei tanto de República no começo do artigo. Não é nem um e nem outro. Organizações são Propriedades Privadas que precisam ser gerenciadas. A organização como um todo, em sua fundação, não pode ser “democrática” para seus funcionários não-acionistas, por definição. Uma sociedade anônima ou algo parecido pode ter uma organização até quase “republicana”. Mas onde queremos estudar e interferir, que é o dia-a-dia gerencial de equipes de funcionários, é um “silo” com implementações “participativas” dentro de um invólucro que não é democrático.

E o objetivo dessa explanação tão longa, é que se você pensar tempo demais na definição coloquial do termo “Democracia”, ela rapidamente evolui para “Coletivismo”, “Populismo”, “Comunismo” e “Socialismo”. Eu sou absolutamente contra essa linha de evolução. É filosoficamente insalubre. No âmbito político ela deve parar na “República”. E no âmbito de negócios é simplesmente “Capitalismo”, sem tirar nem colocar nada.

Claro, o para variar, o título deste artigo “Organizações Democráticas não Funcionam” é uma provocação óbvia ao fato que eu estou me corrigindo quando ao uso errado do termo “Democracia” quando na realidade estamos falando em “Organizações com Processos Eficientes”, particularmente os que crescem organicamente com conceitos no estilo evolucionários-darwinistas, como o Lean/TPS.

Enviar e-mail em aplicações web é uma tarefa comum, mas sempre temos que decidir como elas serão enviadas: servidor SMTP, GMail, Sendmail, serviços como Postmark e Mad Mimi… Todos eles são alternativas viáveis, algumas mais simples, outras nem tanto assim. No final de 2010 a Amazon lançou o Amazon SES (Simple E-mail Service), um serviço [...]

Trabalhar com PDF é um problema em quase todas as linguagens. Existem algumas alternativas, mas quase sempre o processo é trabalhoso ou as ferramentas são caras demais. E é justamente pensando em resolver este problema que o Gregory Brown criou o Prawn, uma biblioteca Ruby extremamente simples de usar, muito rápida e completa, como você [...]

Não deixe de acompanhar semanalmente o Grok Podcast!

Um convite formal para o próximo convidado especial do Grok Podcast!

Ano passado, depois de muito prorrogar, decidi dar uma olhada em Node.js. Muita gente falando bem, rodar JavaScript do lado do servidor seria, no mínimo, interessante. Como tudo que começo a aprender, gosto de definir alguns objetivos. Caso contrário, a coisa fica muito chata. Então decidi escrever um chat, exemplo clássico de "Hello World" do [...]