29 fevereiro 2008

Simpósio Brasileiro de Qualidade de Código 2008









Saudacoes!!
Bem, aos interessados em seguir nesta área, ai vai a dica:
Em Florianópolis haverá o evento nacional de qualidade de software... e existe inclusive uma chamada de trabalhos para M
etodos, experiências e Modelos Ágeis! (será que vou arriscar??)

Apenas dos preços salgados para quem não é aluno nem do meio, pode ser uma ótima oportunidade para observar o que está acontecendo na comunidade acadêmica de desenvolvimento de software (onde até pouco tempo, existia uma aversão imensa sobre qualquer coisa que fosse referente à palavra "Ágil")...


é estamos melhorando...

[]s

I want more porn...

Momento distração... já que estamos em plena sexta feira!


26 fevereiro 2008

Technical debt -- Introdução ao Débito Técnico

Conceito



O termo descreve a obrigação que uma empresa adiciona a um projeto de software quando escolhe uma abordagem de desenvolvimento que permita um resultado rápido que aumentará a complexidade do software e que custará muito mais caro a longo prazo.

Inserido acidentalmente

Uma abordagem tecnológica não adequada ou o código inserido por um programador inexperiente. Este é o resultado não estratégico de um trabalho mal desempenhado. Pode ser criado, ironicamente, na tentativa de refatorar algum setor de código problemático sem o auxílio de mecanismos de verificações/validações.

Inserido intencionalmente



Ocorre com a decisão da empresa em favorecer conscientemente o resultado presente em detrimento dos ganhos futuros. Entre os exemplos mais comuns e mais preocupantes: “Se não entregarmos esta release no prazo, não haverá outra entrega”, ou ainda “se não esta features não for implementada, perderemos N clientes”. A escolha em deixar para o futuro a preocupação com a qualidade do código produzido é o principal motivo para a ampliação dos custos de manutenção.



Identificar o Débito Técnico

  • Existe um único desenvolvedor capaz de tocar em “certas partes do código”

  • Desenvolvedores não possuem confiança em estimar o esforço em realizar atividades

  • A falta de validação/testes dificulda a confiabilidade no sistema. Desenvolvedores dificilmente garantem o funcionamento do sistema

  • Inserções no sistema são feitas e entregues rapidamente, mas levam muito mais tempo para realmente estarem utilizáveis no sistema (retrabalho)



Aprofunde Conhecimento

25 fevereiro 2008

Cockburn e Use Cases



Lendo o blog do Tyner Blain me deparei com post comentando sobre a posição do Alistar Cockburn sobre Casos de Uso e desenvolvimento Ágil.

Entre as principais motivações para utilização de Casos de Uso:

1. The list of goal names provides executives with the shortest summary of what the system will contribute to the business and the users. It also provides a project planning skeleton, to be used to build initial priorities, estimates, team allocation and timing. It is the first part of the completeness question.
2. The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do. It provides the context for each specific line item requirement, a context that is very hard to get anywhere else.
3. The extension conditions of each use case provide the requirements analysts a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget. It provides a look ahead mechanism, so the customer / product owner / business analyst can spot issues that are likely to take a long time to get answers for. These issues can and should then be put ahead of the schedule, so that the answers can be ready when the development team gets around to working on them. The use case extension conditions are the second part of the completeness question.
4. The use case extension scenario fragments provide answers to the many detailed, often tricky business questions progammers ask: "What are we supposed to do in this case?" (which is normally answered by, "I don't know, I've never thought about that case.") In other words, it is a thinking / documentation framework that matches the if...then...else statement that helps the programmers think through issues. Except it is done at investigation time, not programming time.
5. The full use case set shows that the investigators have throught through every user's needs, every goal they have with respect to the system, and every business variant involved. It is the final part of the completeness question. (And yes, I did indeed sit down and walk through 240 use cases with a client, at the end of which, I turned to her and asked: "And is that everything?" She said, Yes, and we built that, delivered it, got paid for it, and it is still in use ten years later.)


Mas o mais importante desta leitura está a apresentação abaixo. Realmente me fez pensar um pouco sobre a forma que tratamos User Stories, e de que maneira, mudando-se o foco, poderíamos utilizar Casos de Uso para ampliar a visibilidade e o conhecimento de todos da equipe sobre o domínio da aplicação, e mais do que isso, de que maneira esta abordagem se encaixa ao Desenvolvjmento Ágil

Leitura Obrigatória número 4300

Download do Arquivo: Agile Use Cases

22 fevereiro 2008

Willian Demin



Frase da Semana

"Não existe necessidade de mudanças. Sobrevivência é fundamental"

[]s

19 fevereiro 2008

Bob Martin e Jim Coplien


Saudações!!
Ok, eu sei... fui fominha... estou "kibando" o debate entre Uncle Bob e Jim Coplien... O BICHO a conversa deles... cada vez mais percebo o quanto ainda preciso estudar... que merda, lá se vão minhas cervejas do final de semana....
Video somente disponível no site (feed nao está listando o video embed)








Introdução



Debate ocorrido na JA00 '07 entre Bob Martin e Jim Coplien. (Leitura Obrigatória número 41220).
Olha a afirmação do Uncle Bob:"Nos dias de hoje é irresponsabilidade para um desenvolvedor liberar uma linha de código que não tenha sido executada em um teste unitário". A discussão gira em torno desta afirmação, além de a defesa de Design by Contract por Jim... além disso: Quanto de design devemos nos preocupar no início de um projeto? Quanto se análise é necessário para que nossos sistemas sejam consistentes com o modelo de domínio do negócio?





Bio


Bob Martin is an Agile Manifesto author, and author of books on Agile Programming, XP, UML, O-O Programming, and C++. He is CEO and president of Object Mentor www.objectmentor.com/

Jim Coplien is a software pioneer in o-o programming and C++ and multi-paradigm design. He appreciates the human side of design, and has written critically acclaimed books on design and development.




This is Floyd Marinescu



I am here with Jim Coplien and Bob Martin at the JAOO Conference and here we have 2 very interesting divergent opinions on what is the value of TDD. So let's open up the floor and let each one have a couple of minutes of say. Let's hear you guys talk about it!



Bob Martin: First thing I need to say is: I am sitting here next to one of my heroes. I read Jim's book in 1991-1992, changed the way I thought about software, changed the way I thought about C++ in particular, so it's a great honor for me to be here. I think we have a disagreement - I'm not sure, possibly, it may a difference in perspective - but my thesis is that it has become infeasible, in light of what's happened over the last 6 years, for a software developer to consider himself "professional" if he does not practice test driven development.




Jim Coplien: Well it may be good, because you did this at your keynote yesterday: you said what you mean by "test driven development". I have adopted a very strong position against what particularly the XP community is calling test driven development. And I have audited this versus a lot of tutorials at about 4 conferences in the past 6 months and they give a very consistent story on what they mean. Here, it was a little bit different yesterday, so maybe for the sake of making this a meaningful conversation you can quickly reiterate so we are on the same page.



B: So I have 3 laws of test driven development. The first one is: a test driven developer does not write a line of production code until he has written a failing unit test, and no production code can be written until there is a failing unit test.<br/>




J: Per se, the main concerns I have about TDD are not problematic with respect to what you've just said in isolation, so if it's no more and no less than that we may not have a big disagreement. What my concern is, then, comes out of doing broad work with a lot of clients and a little bit of interactions with other consultants and other scrum masters who have seen these things happening in their project. And we've seen 2 major problems: one is that use of TDD without some kind of architecture or framework into which you're working - which was very strongly Kent's original position: you use TDD to drive your architecture - leads to a procedural bottom-up architecture because the things you are testing are units.



We just had a discussion upstairs about "is TDD the same as unit testing?" Well, no, it's a little more, but unit testing was a great idea in Fortran, when you could build these layers of APIs and the units of organization of the software were the same as the units of testing, but today the units of organization of the software are objects and we're testing procedures and there is a little bit of a mismatch. Now, if you are using the procedures to drive your architecture, I think you are trying to build a 3 dimensional structure from 2 dimensional data, and you end up going awry. And one of the things we see a lot, in a lot of projects, is that projects go south on about their 3rd sprint and they crash and burn because they cannot go any further, because they have cornered themselves architecturally. And you can't refactor your way out of this because the refactoring has to be across class categories, across class hierarchies, and you no longer can have any assurances about having the same functionality.



The other problem we've seen is that this destroys the GUI and this is what Trygve [Reenskaug] and I talk a lot about, because you have this procedural architecture kind-of in a JAVA class wrapper; you no longer are driving the structure according to domain knowledge and things that are in the user's conceptual model of the world, which is where object orientation came from. I mean even Kent, as he's very often said: "you can't hide a bad architecture with a good GUI." The architecture will always shine through to the interface, and I strongly believe that, and that is why I believe we need something in the infrastructure that gives you a picture of what the domain model is out at the interface. Then, if I want to apply Uncle Bob's 3 rules I probably don't have a problem with that, but I want a starting place that captures this other dimension, which is the structural dimension.



Alright. But you do not accept the thesis that the practice of test driven development is a pure requisite to professional behavior in 2007.



I absolutely do not accept that.




OK. So we can come back to that one because I think that is an interesting topic, just on the topic of professionalism, but before we do that: there has been a feeling in the Agile community since about '99 that architecture is irrelevant, we don't need to do architecture, all we need to do is write a lots of tests and do lots of stories and do quick iterations and the code will assemble itself magically, and this has always been horse shit. I even think most of the original Agile proponents would agree that was a silliness. I think if you went and talked to Kent now he would be talking about what he always talked about: metaphor, whatever the heck that was.



And in fact he says this, in "XP explained" or something, his page 131 of his book he says: "Yes, do some up-front architecture, but don't knock yourselves out".



Sure. OK. But now let me come back and throw a different light on this. I think architecture is very important, I've written lots of articles and books about architecture, I am the big architecture freak. On the other hand I don't believe architecture is formed out of whole cloth. I believe that you assemble it one bit at a time, by using good design skills, by using good architectural skills, over the weeks and months of many iterations. And I think that some of the architectural elements that you create, you will destroy; you will experiment in a few iterations with different forms of architecture. Within 2 or 3 iterations you will have settled into the architecture you think is right and then be entering into a phase of tuning. So my view of that is that the architecture evolves, it is informed by code that executes, and it is informed by the tests that you write.




J: I do agree that architecture evolves, I do believe it's informed both by the code that you write and, maybe even earlier, by use cases that come in, that inform you about things that are relating to scope and other relationships; but if you try to do things incrementally, and do them literally incrementally, driven by your interaction with the customer without domain knowledge up-front, you run the risk that you do it completely wrong.


I remember when I was talking with Kent once, about in the early days when he was proposing TDD, and this was in the sense of YAGNI and doing the simplest thing that could possibly work, and he says: "Ok. Let's make a bank account, a savings account." What's a savings account? It's a number and you can add to the number and you can subtract from the number. So what a saving account is, is a calculator. Let's make a calculator, and we can show that you can add to the balance and subtract from the balance. That's the simplest thing that could possibly work, everything else is an evolution of that.


If you do a real banking system, a savings account is not even an object and you are not going to refactor your way to the right architecture from that one. What a savings account is, is a process that does an iteration over an audit trail of database transactions, of deposits and interest gatherings and other shifts of the money. It's not like the savings account is some money sitting on the shelf on a bank somewhere, even though that is the user perspective, and you've just got to know that there are these relatively intricate structures in the foundations of a banking system to support the tax people and the actuaries and all these other folks, that you can't get to in an incremental way. Well, you can, because of course the banking industry has come to this after 40 years. You want to give yourself 40 years? It's not agile.


So you want to capitalize on what you know up-front, and take some hard decisions up front, because that will make the rest of the decisions easier later. Yes, things change; yes, architecture evolves; and I don't think you'd find anyone who will say "put the architecture in concrete". I also do not believe in putting the code in place, that is, the actual member functions, up front. You put the skin, you put the roles, you put the interfaces that document the structure of the domain knowledge. You only fill them out when you get a client who is willing to pay for that code, because otherwise you are violating Lean. So you do things "just in time," but you want to get the structure upfront, otherwise you risk driving yourself into a corner.



So I would say that a little differently, and take exception to some of it. I would not very likely fill in the interfaces with abstract member functions or defunct member functions. I might create objects that will fill the place of interfaces. So, in Java terms, I might have an "interface-something" with nothing in it, but I am not going to load it with a lot of methods that I think might be implemented one day. That is something that I am going to let my tests drive, the requirements drive, and I am going to be watching it like a hawk to see if there is any kind of architectural friction that would cause me to split that interface.



But the problem is: that's like saying that words have meaning apart from any definition. And so the fact that I call something a mule, without saying what a mule is, doesn't make it a mule. Like Abraham Lincoln said, "Calling a mule an ass doesn't make it one." And so the thing that gives meaning to stuff is the member functions as semantics. You don't want to go crazy and you don't want to be guessing, and here is where I agree with Kent. He says in the "XP Explained" book: "You don't want to be guessing" and that is true. But I do want to assert what I know and there are some things you just know about the structure of a telecom system, a banking system. You know that you don't build a recovery object. I was on a restructuring project in a large telecom company once where they were redoing a toll switch using object oriented techniques and modern computer science techniques, and I got assigned to work with the guy who was making the recovery object. Well this is ludicrous, recovery isn't an object, but yet his superficial knowledge of the domain let him do that. If you get down to understanding what the member functions of that are then you will see this isn't even an object. So you ask: "How do I know it's not an object? What are its member functions?" "Uh... to recover". "Great. That is a lot of help." Actually I think there are people who have capitalized on this and it's now called SOA. That is the danger.


You want to have something there to give the object meaning.



OK. And I would even agree with that. You need something there to give the object meaning. I am going to be really minimal about that.



Me too. No disagreement.



And then I am going to let executing code inform my future decisions, so I am not going to create a massive architecture, or a huge system based on speculation.



That is right. No disagreement.




So back to the beginning: how long would you spend before you started writing executable code. Let's say, on a system that will eventually wind up being two million lines of code?




So, 2 million is, in my experience, pretty small. I am working with hundreds of millions. Before the first executing code... it depends a lot on the individual system, but let's say I were building a simple telecom system. What I would probably do, let's say I am doing it in C++, I would have at least constructors and destructors in place and be able to start to wire up important relationships between the objects and...



Would you have tests, testing those wirings?




I would have tests for those wirings. An obvious test is to make sure, when the system comes up and goes down, that the memory is clean, for example. Half an hour.



Excellent. So where is our disagreement? Perhaps our disagreement is on the notion of TDD and professionalism. That was the second part.



I think that is a separate disagreement, but maybe we can put this one to rest, this is nice. But the thing I want to make clear for the audience is that, again, I think when I am running into people that are doing things right, that avoid the kind of problems they talked about earlier, it's not TDD out-of-the-book or TDD out-of-the-box. So, people have found a way to move to what Dan North now calls BDD, for example, which I think is really cool (if you ignore the RSpec part and all the stuff which is kind of dragging it back to too low of a level).


So there are a lot of people doing the right thing and my concern is that they are calling this good thing TDD and then people are going to buy books and they are going to look up TDD and they are going to find this old thing which is "architecture only comes from tests," which I have heard four times in tutorials in the past 6 months, and that is just, like you say, horse shit. But now, on to the professionalism issue, how would you know a professional if you saw one?




They practice TDD? (smiling)



"Professional," to me, is just someone who makes money for doing a job in that area.




Yeah, I know, and I am going to push on that one, because I think that something our industry has lacked is a standard of professionalism.



We'll take your definition as a starting point and then we can talk about that.




But that is not actually my definition, I was joking. I think that nowadays it is irresponsible for a developer to ship a line of code that he has not executed in a unit test, and one of the best ways to make sure that you have not shipped a line of code that you have not tested is to practice TDD.



J: I do disagree with that. Now, I think there is something deeper that is important, and let me attack this by example. As an example of something I could do as an alternative: I could wave my hands and say a lot of things about code inspections or pair programming and those are good and probably have more value, but it's kind of an independent discussion. But let me give you something that I think hits the nail on the head even more importantly. Let's look what a unit test is. What a unit test does is: looks at an AP of a procedure and kind of goes and hits the state space of the arguments and maybe hits a half a dozen of them, or a hundred or a few million of (2 to the 32nd power) or whatever, and so you're just doing hit and miss. That is really heuristic, you've got to be really lucky to find bugs doing that.


What I think is more powerful is "design by contract." So you have preconditions, post conditions and invariants. Now, the technology isn't there in most languages. They haven't matured to the point where Eiffel has, where you can statically check these things, but you can build additional infrastructure to do that kind of thing. I think it has all the advantages TDD, there are these advantages (supposed advantages), about: I am going to think hard about the code, I am going to focus on the external view and so forth. And I have found, at least for me, that contracts do that more effectively than tests do. Furthermore, they actually give you broader coverage because you are covering the entire range of the arguments rather than just randomly scattering some values in there.



Now, Bertrand Meyer actually taken this further and he has something called CDD, which is Contract Driven Development, where what he does is: he takes contracts and he kind of feeds random numbers at them and if they don't meet the preconditions you don't run them because you know that test will fail, but he tests if the post conditions hold after you run the test, and if they don't it's a bug. And they have actually done this. They have a tool that automatically runs tests. They have done this on the Eiffel library and they ran it about a week, they found 7 bugs in the 20 year old Eiffel library - that is kind of interesting. But it comes from a part of the code where you are expressing intentionality in a way that has hope of being traced back to something of business importance, and the problem about TDD, as most people practice it down at the class level, is that it's really, really difficult to trace those APIs at a class level sometimes all the way up to business significance.




So I am having trouble with that. As I remember Eiffel - and I actually thought this discussion was put to bed a long time ago - as I remember Eiffel and "design by contract," you specify preconditions, post conditions and invariants around every method and around your class, the invariants of your class. Test driven development, or a suite of unit tests, virtually does the same thing, it specifies a set of incoming checks on the arguments, outgoing checks on the returned values, explores the state space, as you said, of the methods. So I always thought that they were one-to-one, you could always transform contracts into unit test or transformunit tests into contracts, with the exception that the direction of the dependencies is different, and you know that I am a big dependency freak. Unit tests depend on code, on production code, which I think is good, production code doesn't depend on unit tests; whereas contracts are smeared through the code, which bothers me.




I think you are creating a dualism that needn't be created, in that there is one thing, which is the code, the code is the design, it's what's delivered, anything else is not Lean. In typical projects that use unit testing, the code mass is about the same as a test mass, and where there is code, there's bugs. You cut your velocity in half. There is well known examples, the most famous example is the ADA compiler where actually, use of test driven development increased the number of bugs in the code, because your code mass increases, because you have more tests. If you are using assertions you have this nice coupling, that is essential coupling, between the semantics of the interface and the code itself. Whereas with the tests the coupling is a lot messier and hard to manage. There was another point you've made I was going to react to...



I am surprised that you think the code mass is different.




J: In my experience, it is. If I look at how people actually use this: I like it when I see a JUnit spec that looks like assertions, but a lot of the time it isn't.



I agree with that: there are messy tests, but there is messy code. I don't like arguments that the "tool is easy to abuse therefore you shouldn't use it," that would invalidate almost everything...




That isn't my argument. My argument is: how I am seeing this being used in broad practice - and they are not getting it.



Well, OK. And do you see contracts being abused in broad practice?



First of all, they are not being used enough...




Right! By the way, since we've just got a couple of minutes left, just a trivia question - and I don't know the answer. Who is it that first used "DD" with some letter in front of it? We've got CDD now, we've got BDD, TDD and I don't know what else and the earliest one I can remember is Rebecca Wirfs-Brock, Responsibility Driven Design. Was there an earlier one?



DD ... was a UNIX command to do disk dump... but that probably doesn't count. Thank you Bob, good seeing you again.





18 fevereiro 2008

User Stories em Português



Ta bom, ta bom... foi mais rápido do que eu pensei... mas taí:

Introdução a User Stories


Apresentação em ppt: Arquivo

Introdução a User Stories

User Stories Presentation Kelly Waters transforma alguns de seus post em mais de uma apresentação...

Estou traduzindo a apresentação, se Kelly e Deus quiser (se um autorizar e o outro deixar) logo disponbilizarei a versãp em português.... Enquanto isso, veja a descrição que o Vinícius apresentou em seu blog

15 fevereiro 2008

MrMason no CampusParty



Saudações!

MrMason, do CocadaBoa participa do CampusParty fazendo o que sabe de melhor: piada da cara dos outros. Neste post, ele apresenta as tribos do evento. Entre gamers, modding, software livre e robótica, encontramos a tribo dos desenvolvedores:

Fonte: http://colunas.g1.com.br/blogdoconvidado/2008/02/11/entenda-os-geeks-da-campus-party/
Desenvolvimento:
Estes são os geeks extremos. Se comunicam em um idioma incompreensível até mesmo para os demais grupos geeks da Campus Party. Eles que fazem os nossos computadores pensarem. Sabe quando o seu Windows congela? A culpa é deles. Sabe quando o sistema está fora do ar bem na hora em que você precisa passar o seu cartão de débito? A culpa é deles. Sabe quando você perde todos os seus dados porque tentou ver umas fotos da Flávia Alessandra nua? A culpa é deles. Enfim, se eles não existissem, os computadores seriam bem mais eficientes.

[]s

09 fevereiro 2008

Eat your own dog food

Enviado por Marcio Marchini

Fonte: Kirk


Quite a few moons ago, I interviewed a gentleman working for a CASE tool vendor. They had just shutdown one of their development shops, and employees had two choices. Find another job, or be relocated. This chap decided to go searching, and our paths crossed. It didn’t take long for me to get way off track with my questions, and eventually I point-blank asked him if they used their own CASE tool on internal development projects. He said “no”, and then nervously suggested that we get the interview back on track. I can’t recall if we ended up hiring the guy, but that interview left an indelible impression and taught an important lesson. If the guy who developed the software doesn’t use it, then you shouldn’t use it. How many open source projects do you think are created where the authors have never used the tool or framework? I’m guessing very few. How many product companies develop products that they don’t use internally? I’m guessing quite a few.

It’s a pretty simple question to ask the next tool vendor trying to sell you their product. If they say yes, then ask them what they like and dislike about the tool. Their honesty is apparent.

08 fevereiro 2008

10 Maiores inovações da década



Juntamente com TetraPak, Embraco e Banco do Brasil, um dos sistemas
da Audaces Automação foi escolhido como uma das 10 maiores inovações brasileira da última década... e agora com desenvolvimento Ágil a expectativa é que o crescimento seja vertiginoso... =)
É um Brasil em busca de resultados como estes que devemos criar...

Fonte: Revista Exame
http://portalexame.abril.com.br/negocios/m0151118.html

Digiflash - Audaces

O empenho pessoal dos sócios da Audaces Automação, de Santa Catarina,
também impulsionou outra inovação escolhida pelo conselho de O Brasil
que Inova. Colegas de faculdade – formaram-se em Ciências da
Computação em 1992 –, Claudio Grando e Ricardo Cunha criaram um
produto inédito na indústria da moda em todo o mundo, hoje exportado
para 30 países. O Digiflash consiste em reconhecer as medidas exatas
de um molde de roupa por meio de apenas uma foto, tirada por uma
câmera comum, em qualquer ângulo. A importância do software é que ele
substitui um método braçal de digitalização de moldes, que obriga
modelistas a praticamente redesenhar a peça em uma mesa digital, com a
ajuda de um mouse. (No departamento de criação de marcas como a Opera
Rock, o uso do Digiflash economiza até 75% do tempo de digitalização).
Chegar à versão final do programa, no entanto, demandou três anos de
esforço e pesquisa dos sócios da Audaces – e uma certa nostalgia dos
tempos de colégio. "Voltei aos livros de física, que havia abandonado
há pelo menos vinte anos", afirma Cunha. As horas de estudo para
compreender como a ótica influencia o desempenho do Digiflash geraram
fruto: vendas que hoje chegam a 15% do faturamento da Audaces,
superior a 10 milhões de reais.

Fonte: Revista Exame
http://portalexame.abril.com.br/negocios/m0151118.html

PS: estamos contratando

04 fevereiro 2008

Fatboy Slim em Florianópolis



Show? que show? Foi um espetáculo! :-)

O DJ veio de novo ao Brasil e desta vez passou pela ilha da magia, e minha casa: Florianópolis... e com certeza fui conferir! Destaque para o Telão de LED de alta resolução - impressionante demais! Com um pouco mais de 2 horas de show, foi um dos melhores que eu já assisti...

Agora vou contar um pouco do que não foi tão legal assim...

EL DIVINO É UMA PORCARIA



Cara, eu me pergunto onde está o bom senso dos organizadores... e pior, com certeza eles devem estar dando pulos de alegria com o dinheiro arrecadado. E a ganância com que o evento foi tratado seja a ser vergonhosa... bem... cheguei no evento à 01:00 da manhã...
Alguns detalhes da desorganização total:


  • Falta de policiais suficientes: Com certeza meia dúzia de policiais não poderia dar conta de pelo menos 3 mil pessoas seguindo em direção ao evento. E o que aconteceu?? Uma fila monstruosa na SC - com turistas pondo em risco a vida de pedestres (malditos!), arrombamento de carros e brigas. Culpa da polícia? NÃO - DA MERDA DA ADMINISTRAÇÃO DO EVENTO que mão mensurou direito o tamanho do evento

  • Convite: Cara, isso foi hilário, pra não dizer trágico... O site NosVamos vendo convites antecipados para "maior comodidade" dos espectadores... mas chegando lá no EL DIVINO DE MERDA, mais fila, ou melhor: tumulto... pq??? para atender ao menos 300 pessoa (por baixo) com apenas 2 guichês de convites (sim - vc tinha que retirar o convite lah na hora!!) foi um inferno!!! Tive que me degladiar por quase uma hora até pegar os dois convites suados que comprei pela internet... sem contar alguns princípios de briga, xingamentos mil e promessas de "Maldito el divino - vcs vao queimar no fogo do inferno!!!". Ridiculo!

  • Em fim entrei!! Obviamente o show já havia começado (às 02:00 da manhã)... tudo lindo, maravilhoso... até que a minha patroa precisa de água... Imagine-se num mundaréu de gente... com apenas 4 casinhas para comprar ficha de bebida. Lá vou eu de novo no empurra-empura pra comprar 3 fichas de água. Mas agora vem o melhor!!! Buscar a água!. Pior ainda ainda a situação, existiam apenas 4 quiosques para atender 3 mil pessoas!!! Extremamente mal localizados, lá vou eu mais uma vez me embrenhar no meio de um monte de gente desta vez para salvar a patroa da sede... com as águas na mão, voltamos ao show!

  • Banheiro??? pra quê? pra comecar não tem nada perto do palco... é necessário se deslocar até dentro da casa para ir ao banheiro - obviamente entupido de gente...

  • O telão de LED era realmente show de bola! Credo!

  • Com o término do show, eu não queria outra coisa a não ser: minha casa! Preciso dizer que o flanelinha que cuidava do carro, e que disse: "podexá campeão, qdo o senhor voltar nois tái, tá tranquilo", não estava por lah né??? E pra finalizar a noite: meu carro atolado! Só podia ser piada neh... mas não foi... isso que dá chegar tarde na balada e botar o carro em qqer buraco... lá fui eu chamar o sogrão com a caminhonete 4x4 pra tirar o carro do buraco...



ORIENTAÇÃO DA POLÍCIA

Segundo orientação da polícia militar neste dia: Todos aqueles que se sentirem lesados devem se dirigir a uma delegacia e prestar queixa ao El Divino Club. Por tanto se você está nessa situação: manda bala no B.O.!!


Apesar do saldo positivo da noite (com o show animal), muito poderia ter sido evitado se a diretoria do El Divino não fosse gananciosa o suficiente para economizar um pouco e prover uma experiência mais agradável às pessoas... sinceramente... era só um dos sócios daquela merda de lugar tentar usar entrar na própria casa como uma pessoa qualquer... simples, mas já daria uma boa visão de como akele lugar é uma porcaria!