Dojo@Centro 5/06/2013 – Pintando árvores

domingo, 9 junho 2013

Olá, pessoas queridas. Tudo bem?

No dojo@centro da última quarta feira, o problema que tentamos resolver foi o seguinte:

Dada uma árvore binária, só podemos pintar o nó se o nó pai já estiver pintado. Cada nó possúi um valor correspondente e a ordem da pintura é multiplicada ao valor do nó, correspondendo ao tempo de pintar o nó. Sabendo disso, qual é o menor tempo para pintar todos os nós da árvore?

Com isso, temos um conjunto de nós pintados e um conjunto de nós candidatos a serem pintados e temos que encontrar a ordem dos nós que resulta no menor tempo de pintura. O problema original pode ser visto aqui

No tópico do dojo deste dia, foi postada uma consideração sobre o problema:

É um problema de job scheduling. Parto do princípio que a maior tarefa existente, quando for possível fazer (i.e. o pai já tiver sido colorido), necessariamente vai trazer o maior ganho imediato *e global*. Isso significa, em outras palavras, que a maior tarefa precisa ser executada necessariamente logo depois da tarefa pai dela. Assim, eu posso mesclar os dois nós em uma tarefa só (pois elas sempre precisam ser executadas juntas). Mas, para isso, precisei generalizar o problema.

No problema original, as tarefas tem um tempo para ficarem prontas (inicialmente todas tem tempo 1) e a penalidade é dada pelo tempo do final (não pelo do início). Mudei para o tempo ser calculado a partir do início da tarefa pela função linear at + b. Então, inicialmente, todas as tarefas, que tinham penalidade a*t, passam a ter penalidade a*t + a, onde a é a penalidade da tarefa como descrita pelo problema. Toda vez que mesclo duas tarefas cujas penalidades são a*t + b e c*t + d, onde a primeira precisa ser executada antes da segunda, tenho que a nova penalidade é:
penalidade(A+B) = (a + c)*t + (b + d) + c*duração(A)
duração(A+B) = duração(A) + duração(B)
O “c*duração(A)” é porque enquanto A está executando, a tarefa B está acumulando penalidades proporcionais ao tempo perdido executando A.
Se a maior tarefa não tem nenhum pai na árvore (ou seja, ela pode ser executada imediatamente), executo e incremento o tempo. Senão, vou reduzindo a árvore efetuando esses merges.
Mantenho a lista de tarefas ordenadas usando set (e não uma heap, principalmente porque preciso poder remover uma tarefa no meio da lista), e para simplificar as operações na árvore, mesclo duas tarefas usando union-find (para evitar ter que percorrer as tarefas filhas atualizando seus pais).
A solução que conseguimos está no repositório Github do dojoRio
Este dojo também teve uma versão de brigadeiro feito pela Cissa Belém para comemorar o aniversário do Elias Tandel. Os dojos de aniversário estão com problemas muito bons, creio que em honra ao aniversariante :), mas além disso, o Elias trouxe uma notícia que explodiu várias cabeças: CSS 3 é Turing Complete
E os participantes que se lambuzaram de tinta foram :
  • Thiago Belem
  • Juan Lopes
  • Otávio Cardoso
  • Andre Oliveira
  • Álvaro Justen
  • Elias Tandel
  • Carlos Cunha
  • Jacqueline Abreu
  • Diego Volpato

E as pinturas bonitinhas que a galera curtiu foi:

  • Problema “profundo” – o falso problema simples, aquele que tem enunciado com aparência de fácil, que só revela a complexidade na hora de implementar +++++++
  • Novatos e o retorno de  participantes antigos ++
  • Novatos
  • Menos bullying com as linguagens
  • Nova versão de brigadeiros bel[eé]m +++++++
  • A vinda da Val Parajara, do Diego Volpato, do Júlio Marins e do Leonardo Alberto (Leobeto)
  • Aniversário do Elias Tandel +
  • Comida +++
  • CSS 3 Turing Complete +++
  • Ruby +++
  • Retorno ao dojo
  • Árvore (Estrutura de Dados)
  • Rule 110

E as manchas no chão que teremos que limpar foram:

  • Falatório ++++++
  • Ar condicionado não está funcionando direito ++++
  • Israel e Claudio Berrondo não puderam vir +
  • Fonte de dojotimer não estava ok
  • Entender um pouco mais de ruby
  • Webdings +++
  • CSS 3 não deveria ser turing complete (está fazendo mais do que deve)
  • O dojo começou tarde ++
  • Explicar várias vezes o problema atrasa o andamento do dojo
  • [] != NIL
  • Bel[eé]m fêmea, vulgo Cissa, não participou
  • Receber ligações telefonicas na hora em que está pilotando
  • O problema pareceu não estar muito adequado a ser feito seguindo a lógica do TDD. A implementação da solução foi muito exaustiva
  • Poucas bebidas
  • Apesar de menor, ainda teve momentos de bullying com as linguagens
  • Não consegui participar ++

E este foi o dojo@Centro desta semana e semana que vem tem mais. Se você quer mostrar para a sua namorada ou namorado que programação também pode ser feita em grupo e divertida, pode levar a pessoa ao próximo dojo :).

A Íparos agora está se tornando o espaço #CurtoCircuito. Para saber mais, leia o post da @CissaBelem sobre ele – é uma versão bastante simplificada sobre o espaço, veja outras informações na fan page do espaço e também veja o http://curto-circuito.org/ :D.

E se você gostou de tudo isso, esteja conosco na próxima 4º feira, na  Av Treze de Maio, 13 – 6° andar – Cinelândia, entre 18:30 e 19:00. Só não tem dojo@Centro se a 4º feira for dia de feriado . Qualquer dúvida, é só mandar email para o  grupo (google groups) do dojo, alguém do grupo sempre responde as dúvidas conforme for possível ou um tweet com a hashtag #dojoRio.

Você é muito bem vindo, de verdade :D.

Até a próxima o/.

Anúncios

DojoRio@UFF – 15/06/2010 Em ritmo de Copa

quarta-feira, 16 junho 2010

Galera,

Rolou ontem mais um DojoRio@UFF. Só para lembrar, esse Dojo é regido pelos calouros do Curso de Ciência da Computação com o intuito de eles aprenderem entre si, já que a discrepância entre as diversas turmas das disciplinas Programação I e II do curso é bem grande.

Para manter o clima de Copa do Mundo, o problema foi fazer um avaliador de bolão. De entrada era esperada duas ou mais apostadores, suas respectivas listas de apostas e uma lista com os resultados finais das partidas. A saída deveria ser o nome do apostador que foi vencedor e a pontuação que ele obteve. Diferentemente da Copa e felizmente, nós não tivemos vuvuzelas presentes na sessão.

O código resultante está nesse repositório no Github. Como nós usamos o parâmetro para ativar o commit para o repositório git a cada salvamento de arquivo do Dojotools, vocês poderão pelo no histórico de commits como foi a evolução do código e nossos erros.

A abordagem para o problema foi bem discutida e a modelagem que nós adotamos nos ajudou muito a manter o código sustentável. Além disso, o fato de testarmos primeiro os casos de comparação entre dois resultados para depois atacarmos a solução final foi essencial para o entendimento e o desenvolvimento de maneira organizada do código.

Estavam em campos 10 jogadores:

Os pontos positivos foram:

  • O problema +++
  • Biscoitos +++
  • Época de Copa do Mundo
  • Jogo do Brasil no DCE +
  • Explicação do and e or simulados por if’s e o caso ter acontecido depois
  • Começar a realmente entender Ruby
  • Ruby é sexy ++
  • Todos programaram +
  • Dojotools com o git ++
  • Orientação à objetos ++
  • Discussões boas ++++
  • Veio uma galera boa +
  • Ambiente
  • Linguagem nova ++
  • Iniciativa dos calouros propondo modificações no Dojo
  • Modelagem é tudo e resulta em avanço
  • Mouse
  • Quadro impedindo o reflexo do sol
  • Avanço no código da maneira sustentável +
  • O horário

Os pontos a serem melhorados foram:

  • Faltou a apresentação das pessoas
  • Demorou para começar ++++
  • Professor que passa exercício pra nota faltando 5 minutos pro Dojo ++++
  • Faltou tempo
  • Bug do Dojotools
  • Uso radical dos baby steps
  • Ausência de um pessoal ++
  • Comida desnecessária no horário
  • Não poder ver o código ser desenvolvido por inteiro +
  • Mosca imortal enchendo o saco
  • Não entendimento sobre discussões importantes

Como sugestões ficaram:

  • Fazer algum em PHP
  • Fazer algum em C
  • Melhorar a posição do piloto e copiloto

O Dojo foi bastante proveitoso, principalmente em função de duas discussões. A primeira foi fruto da ideai do Lucas de fazer a maioria dos Dojos nesse horário em Java pelo fato de a maioria dos que frequentam o Dojo nesse horário estarem aprendendo Java. Alguns participantes aprovaram e outros não. Enfim, como o Dojo é deles e para eles, eles ficaram de conversarem entre si e decidirem o que vão fazer. Esse fato por si só já é interessantíssimo.

Para não ser injusto com ninguém e nem tendencioso (afinal eu estava dentro da discussão com as minha opiniões) prefiro dizer somente qual foi o assunto da segunda discussão. Bem, a segunda discussão foi tocada em função do conceito de Baby Steps e de como ele funciona em conjunto com o TDD. O importante é que no final todos continuaram com a opinião de que de fato desenvolver software usando TDD e baby steps é altamente produtivo.

Até a próxima,

Bernardo Fontes


DojoRio@Lapa – Xadrez e Openspace

domingo, 13 junho 2010

O nosso encontro do dia 9 de junho de 2010 agradou todas as tribos. Programamos, conversamos, bebemos (para quem bebe) e até fomos chamados de inteligentes :B

Deu também para gravar a chamada para o OpenSpace do dia 19/06/2010 na UNIRio.

O problema:

Dadas as posições das peças em um tabuleiro de xadrez, retornar quais peças estão ameaçando o rei.  Escolhemos como menor passo tratar apenas o peão. E ficamos por ai mesmo.

Participantes:

  1. Raphael de Almeida
  2. Carlos Flores
  3. Israel Teixeira
  4. Vinícius Sales
  5. Lara Mulé
  6. Gustavo Souza
  7. John Cupido
  8. Carlos Carneiro
  9. Oscar Marques
  10. Valéria Parajara
  11. Gustavo Henrique
  12. Claudio Berrondo

🙂

  • Pessoas inteligentes, ou pelo menos pareceu
  • Sala diferente/nova +
  • Estrutura bem maior
  • Ter chegado a tempo
  • Chegamos cedo para fazer carinhas
  • Ruby ++
  • Problema baseado em jogos (xadrez) +
  • Exercício de Modelagem

😦

  • Me deixaram sem jeito
  • Cheguei atrasado +
  • Gostaria de ter visto os comentários finas do problema
  • Estou com problemas com o Ubuntu
  • Espaço muito na “vertical”
  • Pouca gente
  • Berrondo não desapego do código

Sugestões para a próxima sessão:

  • Não interferir na arrumação da sala, o que tirar do lugar, ponha de volta
  • Projetar na parede lateral
  • Providenciar um WiFi

#facts

  • De onde você conheceu o Rodolfo? Sei lá, só sei que ele apareceu.
  • Hoje  (09/06/10) é aniversário do PHP! E….? Vamos comemorar no Pós-Dojo. Agora sim!
  • Minha carinha feliz é a minha carinha feliz.
  • #Comofaz uma tupla em ruby?
  • Tipo um rei
  • Vocês parecem ser inteligentes.
  • A vida não tem edição.
  • O tiozinho “Festa estranha com gente esquisita eu não to legal” falando inglês no meio da rua.
  • O grito da Lara ao ver o tiozinho.
  • Carlos esmolando para sobreviver
  • Bem que o Ernesto podia mudar para o número 42. Mas ele esta no lado impar. É só mudar de lado!
  • A resposta agora é 41.
  • Gauchos de boina.
  • Hoje a mulher misteriosa é a Carina.
  • x4ids é a “Galera da van”.
  • Agora entendi, o videocast é tipo um podcast. Por que será?
  • … então vamos fazer um roteiro para o videocast. Xiii acho que ele está te zoando…
  • “Van” da x4ids com a traseira arriada de tanta gente

Não esqueça de olhar as fotos e o código da nossa sessão.


DojoRio@Niterói – 10/06/2010

sábado, 12 junho 2010

Galera,

Aconteceu nessa última quinta-feira mais uma sessão do DojoRio@Niterói. A sessão foi caracterizada pela heterogeneidade dos participantes. Estavam presentes professores, calouros do Curso de Ciência da Computação, veteranos, mestrandos, profissionais da área de TI, professores, historiadores e até a Luciana Cavalini que atua com o pessoal da Medicina no desenvolvimento do OSHIP.

O problema escolhido foi o do jogo de boliche. Dado uma lista de jogadas compostas por frames das jogadas individuais, tínhamos que retornar o total de pontos. A linguagem utilizada foi Ruby. A entrada foi definida como uma lista de listas e a saída um inteiro que representasse o total da pontuação. O spare era definido por um ‘/’ e o strike por um ‘x’.

O problema caminhou bem, mas o mais interessante foi o fato de o pessoal ter discutido bastante sobre questões sobre a modelagem do problema. Foi bem pensada a maneira de abordar o problema para não cairmos na armadilha clássica na computação de se fazer uma só função que acaba por ter N responsabilidades. Fizemos bastante uso de Orientação à Objetos levando em considerações questões como estado de um objeto e herança. Além disso, rolou uma explicação muito completa sobre o conceito de bloco e o uso dele em Ruby.

Haviam 24 presentes, sendo eles:

A review foi bastante proveitosa e tivemos como pontos positivos:

  • O Dojo continua cheio ++++++++
  • Bastante discussão +++
  • Ter sido em Ruby ++++++++++++
  • Explicação do conceito bloco em Ruby ++++++++
  • Ctrl + Z +++
  • Ambiente físico
  • Calouros participando dos dos Dojos
  • Problema interessante ++
  • Código em inglês
  • Arrumar um estágio pela participação no Dojo
  • Muita gente programou
  • Aprender as regras do boliche
  • Uso de orientação à objetos +
  • Comida +++++++++
  • Coca-cola
  • Refatoração
  • Pessoal que não vinha faz um tempo veio
  • Mas e quando…? Os novos estão começando a saber responder esta pergunta
  • Últimos 4 Dojos = 4 linguagens diferentes = poliglota
  • Aprendizado de convenções e culturas que envolvem a lingaugem
  • Gente nova +
  • 4 C’s (colaborar, compartilhar, comunidade e conhecimento)
  • Aprendizado usando a teoria dos jogos sem perceber
  • Aniversário do Dukão ++++++
  • Pessoal falando mais alto no computador
  • Paticipação da Luciana +
  • Matinhon deu as caras +
  • Mulherada mostrando como se programa
  • O nível da galera
  • Professores presentes +++
  • Informalidade
  • Muitas novidades

Os pontos a serem melhorados foram:

  • Migué do Martinhon +++
  • Bolo para o parabéns
  • Esquema de cores do Gedit
  • Faltou a apresentação inicial do pessoal
  • Abuso de Ctrl + Z
  • Faltou um mouse +
  • Cabeça cheia == código ruim
  • Ter que falar e ouvir as pessoas arrumando as coisas para fechar a sala
  • Computador dos outros dificulta por causa do teclado
  • Acanhamento dos professores +
  • Pessoas indo embora no meio da sessão
  • A entrada não estava clara
  • Ter sido em Ruby
  • Código em inglês
  • As regras do não foram 100% seguidas
  • Atrasos
  • Falatório da platéia +
  • Renata não ter programado ++
  • Ter que aprender a jogar boliche
  • Muito não programaram +
  • Algumas pessoas ficarem de espectadores
  • Ignorância em Ruby
  • Oliver não programou

Ficou como sugestão:

  • Rever o formato do Dojo para torná-lo mais compatível com o número de participantes
  • Definir o problema antes e escrever no quadro
  • Fazer um Dojo em C
  • Fazer um Dojo em PHP
  • Usar um computador mais “default”
  • Continuar fazendo Dojos em Ruby

Esse Dojo se caracterizou por ter sido um dos mais explicativos, digamos assim. Houve muita discussão teórica de boas práticas de programação, o que é essencial para essa garotada nova já começar com o passo certo. Mas, como o Dojo não acaba aí, depois ainda rolou uma MESA GIGANTE na nossa Cantareira que tinha de tudo, desde caipiras até um pessoal nerd programando um programa para sortear os times para um bolão. O fato de eu ter feito o programa (em Python, claro) e o Brasil ter ficado comigo são meras coincidências!

Até a próxima,

Bernardo Fontes


ForkinRioRails 01/06/10

quarta-feira, 2 junho 2010

Ontem (01/06/10) rolou mais um ForkinRioRails no NTP da UFF do Gragoatá.

Os presentes foram:
André Oliveira;
Luciano Sousa;
Mário Mariani;
Rafael Moulin;

O Forkin foi basicamente dividido em duas partes:

De início debatemos sobre o exercício de mapeamento que foi sugerido como extensão do aprendizado.

  • Quase todos fizeram os exercícios;
  • Foram feitos alguns testes no console para testar as validações dos mapeamentos;
  • Rolou um debate muito maneiro quando começamos a pensar nas entidades mapeadas e seus respectivos nomes, que nos levou a pensar em refazer o mapeamento alterando um nome de entidade e criando uma tabela auxiliar para ajudar no histórico dela;

Após isso nos concentramos na apostila, nos capítulos 05(finalizando) e 06.

  • Conversa básica sobre MVC. Café com leite pra galera;
  • Forma como o ERb trabalha, e como utilizamos ele. Nesse ponto calhou uma discussão da maneira de como o REST funciona e como podemos gerar várias actions que podem nos facilitar;
  • Outras formas de gerar views no Rails, além do padrão(ERb).
  • Descobrimos que para gerar uma index geral temos que apagar o index.html no routes.rb e inserir:  map.root :controller =>   ‘controller_que_eu_quero’ no mesmo arquivo, e este deve possuir um método index;
  • Diferenças dos helpers;
  • Partials é uma tremenda mão na roda para criar conteúdo estático que tem de ser gerado em vários lugares. Ex: listas, formulários, etc.
  • Layouts, mais uma das simplicidades do Rails;
  • Filtros; onde colocar filtros; como funcionam os filtros; Não gerar filtros para fazer log, o Rails já possui implementações prontas;

etc…

Apesar de ser um grupo muito reduzido (4 pessoas nas últimas vezes) o ForkinRioRails tem sido bastante proveitoso graças as vantagens do Rails, em tudo ser feito simplificadamente e no grande interesse da galera envolvida.

Para a próxima semana, iremos ler e estudar o capítulo 07 da apostila: Rotas. Todos estão convidados.

Abraços.


ForkinRio[3] de Python

terça-feira, 4 maio 2010

Pessoal,

Aconteceu nesse último domingo a terceira reunião do ForkinRio de Python. Apesar de algumas faltas, o número do pessoal que compareceu foi bastante legal e o novo local – a casa do Vinícius Teles – contribuiu muito para o desenrolar do encontro. Isso sem contar o pessoal novo que apareceu nessa reunião e o Mauro George que merece ser citado por passar por 2 horas de viagem para se juntar a nós.

Estiveram presente no encontro:

Para passar para vocês que não puderam comparecer, vou fazer um resumo dos pontos positivos e do que podemos melhorar que foram levantados na nossa retrospectiva.

Antes de mais nada, a mudança do local e a infra que pudemos usar foi essencial. Espelhamos uma mesma tela em três monitores e todos puderam acompanhar todos os códigos ao mesmo tempo.

O fato de termos dois rubistas presente na reunião acabou por gerar discussões de alto nível comparando as linguagens. As comparações iam desde questões de sintaxe quanto questões bem profundas das linguagens. Entretanto, as comparações não eram para fomentar a competição do que é melhor, mas sim para entendermos as formas de fazer o mesmo comando nas duas linguagens e o que podemos fazer em uma e não podemos na outra.

Como nós não somos capazes de discutir pouco, essas dicussões não se limitaram às diferenças entre as linguagens. Acabamos por levantar um sério questionamento sobre onde usar Java. Também rolou uma conversa muito interessante sobre como é importante, na nossa área, você aprender e trabalhar ao lado de outras pessoas. Para fechar com chave de ouro, tivemos um grande debate sobre orientação à objetos.

Para esse resultado, foi essencial todos terem colocado os códigos que produziram em suas respectivas contas do Github. Pelo formato que o próprio Github fornece, a nossa dinâmica ficou bem suave. Inclusive, surgiu a ideia de fazermos um ForkinRio remoto para termos a experiência (apesar de todos concordarem que o encontro presencial é muito melhor).

Além disso, surgiu a ideia de fazermos um repositório no Github onde colocaríamos o que nós achamos de mais interessante em cada exercício. Assim, geraríamos um apanhado geral do que ficou legal para que o pessoal que não teve como ir à reunião pudesse ver depois.

Além da galera que faltou, o que nós não achamos legal foi o fato de alguns exercícios não terem sido resolvidos e também de não termos colocado em prática algumas idéias como a do Benchmark e a dos podcasts. Entretanto, tentaremos implementá-las na próxima reunão.

Falando sobre próximo encontro, quando será? Bem, para colocar nossa ideia em prática, o primeiro encontro remoto será no domingo que vem, dia 08/05. Sim, nos dias das mães às 09:00. Para não criar muita confusão com nossas mães a reunião deve durar até a hora do almoço já serão pouquíssimos exercícios. Serão somente dois do Google Python’s Class: Log Puzzle Exercise e o Copy Special Exercise.

A reunião presencial, por sua vez, acontecerá no dia 15/05, às 09:00 no esquema de sempre. Para essa reunião serão cobrados a leitura e os exercícios da Parte V do livro.

Espero todos lá!

Abraços,

Bernardo Fontes


DojoCampos[5]

sexta-feira, 5 março 2010

Problema: Triângulo de Pascal

Linguagem: Ruby

Participantes:

Retrospectiva:

Maneiro:

  • Problema interessante
  • Todos participaram
  • Menos atraso que o anterior

Porcaria:

  • Problema nebuloso no início
  • Atrasou um pouco
  • Sem #horaextra

Foto Oficial do dia 03/03/2010

Código disponível em http://github.com/hugobr/DojoCampos/tree/master/2010_03_03/