Introdução à probabilidade para Modelagem Linguística

Com a oferta de alguns cursos sobre Processamento de Linguagem Natural e Machine Learning nos MOOCs por aí,  algumas pessoas, como eu, podem sentir alguma dificuldade em “recordar” alguns conceitos e regras de probabilidades. Depois de garimpar um pouco pela Internet, encontrei uma aula muito boa, dividida em duas partes:


Probabilities and Language Models

Elas foram ministradas pelo professor Jason Eisner, da Johns Hopkins University e foram concebidas justamente com o intuito de ser um apanhado geral sobre probabilidade para NLP para alunos de graduação.

Enjoy.

Uncategorized

, ,

April 14, 2013

Leave a comment

Testing java code with Scala: Maven Setup + Code Coverage on Sonar

Hi, have you ever thought about testing your Java code using Scala? It’s possible!

This post will document all the configuration steps I had to follow to make this work in a maven project using Scala 2.10, ScalaTest and Sonar.

It seemed reasonable to use ScalaTest, specially because it allows us to write tests in more than one style: bdd, tdd and integration.

Adding Scala support to our project

So the first step was to configure maven to recognize my Scala code. For this, we use the maven-scala-plugin, adding to our pom:

<pluginRepositories>
...
    <pluginRepository>
        <id>sonatype-oss-public</id>
            <url>https://oss.sonatype.org/content/groups/public/</url>
    </pluginRepository>
    <pluginRepository>
        <id>scala-tools.org</id>
        <name>Scala-tools Maven2 Repository</name>
        <url>http://scala-tools.org/repo-releases</url>
    </pluginRepository>
...
</pluginRepositories>

<build>
    <plugins>  
        ...
       <plugin>
        <groupId>net.alchim31.maven</groupId>
        <artifactId>scala-maven-plugin</artifactId>
        <version>3.1.4-SNAPSHOT</version>
        <configuration>
          <useZincServer>true</useZincServer>
        </configuration>
        <executions>
          <execution>
            <id>scala-test-compile</id>
            <phase>process-test-resources</phase>
            <goals>
              <goal>testCompile</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
           ...
    </plugins>
...
</build>

The scala-maven-plugin infers the scala version we are going to use from the scala-library dependency. As we are also going to use ScalaTest, let’s add both dependencies right now:

  <dependency>
    <groupId>org.scala-lang</groupId>
      <artifactId>scala-library</artifactId>
      <version>2.10.1</version>
  </dependency>
  <!-- Much better Eclipse integration -->
  <dependency>
      <groupId>org.scalatest</groupId>
      <artifactId>scalatest_2.10</artifactId>
      <version>2.0.M5b</version>
  </dependency>

At this point, you are supposed to add the Scala source directories to your project:

src/main/scala
src/test/scala

Adding ScalaTest support

Ok, we’ve already added the ScalaTest dependency, but we also have to add the ScalaTest maven plugin to our project to make it work:

            <plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-surefire-plugin</artifactId>
				<version>2.7</version>
				<configuration>
					<skipTests>true</skipTests>
				</configuration>
			</plugin>
			<!-- enable scalatest -->
			<plugin>
				<groupId>org.scalatest</groupId>
				<artifactId>maven-scalatest-plugin</artifactId>
				<version>1.0-SNAPSHOT</version>
				<configuration>
					<reportsDirectory>${project.build.directory}/surefire-reports</reportsDirectory>
					<junitxml>.</junitxml>
					<filereports>WDF TestSuite.txt</filereports>
				</configuration>
				<executions>
					<execution>
						<id>test</id>
						<goals>
							<goal>test</goal>
						</goals>
					</execution>
				</executions>
			</plugin>

Notice that we’re disabling the java tests in this project, as all our tests will be written in Scala.

Adding Code Coverage

At this point maven is able to run Scala tests from our /src/test/scala directory. But we want more, we want to know which code and, specially, how much of our code is being covered by these tests, right?

I tried to use cobertura, but I didn’t manage to make it work. After some research, I discovered that Jacoco could help me in this task.

To make Jacoco generate its coverage report at build time, we add the maven-jacoco-plugin to our project:

            <plugin>
				<groupId>org.jacoco</groupId>
				<artifactId>jacoco-maven-plugin</artifactId>
				<version>0.6.3-SNAPSHOT</version>
				<executions>
					<execution>
						<goals>
							<goal>prepare-agent</goal>
						</goals>
					</execution>
					<execution>
						<id>report</id>
						<phase>prepare-package</phase>
						<goals>
							<goal>report</goal>
						</goals>
					</execution>
				</executions>
			</plugin>

At this point, every time we run mvn install, the ScalaTests will be run and jacoco will generate its reports to target/jacoco.exec. You could configure Jenkins (if you use it) to display the coverage reports using the Jacoco Jenkins Plugin, which is quite nice, by the way.

On the other hand, if you use and love Sonar, you certainly will also want the coverage results there, right? Unfortunately, at this point you will have 0% coverage in Sonar.
The easiest way I managed to have code coverage reports in Sonar was to make it read the already generated jacoco reports. To do this, we define the following properties in our pom:

<properties>
...
    <sonar.core.codeCoveragePlugin>jacoco</sonar.core.codeCoveragePlugin>
    <sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
    <sonar.jacoco.reportPath>target/jacoco.exec</sonar.jacoco.reportPath>
...
</properties>

At last!

I had to look at many different sources to finally make it work. I hope it also helps you.
I’m probably writing more about Scala tests in the near future.

Please, let me know if there are ways to improve this setup, ok?

Uncategorized

, , , , , ,

March 31, 2013

2 Comments

Cutting file paths from git status without a mouse

Since I started using git I’ve made a commitment to myself to only use it via its command line interface, no GUIs and no IDE integration, no intermediaries.

Almost everything can be easily done this way. But one thing bothered me for quite some time and today I decided to solve it: how could I select a file from the git status file list without using the mouse?

The problem

Let’s suppose you’ve changed some files and you’re ready to commit your changes. And, just to be safe, you type git status to take a look at all the files you’ve changed. What do you get? Among other other things (help text and #) you will probably have a file list:

  /some long path to file/a
  /some long path to file/b
  ...
  /some long path to file / n

Right now, you find out that file b wasn’t supposed to have changed. How do you rollback the changes you’ve made to it?

Git status by itself teaches you that

  $ git reset HEAD /some long path to file/b

will just do it. The problem is that the files you’ve changed have paths in common, thus typing the whole path, even using TAB for autocompletion, would be costly.

Ok, git is great, and it allows you to do nice things like using wildcards: **/PartOfMyFileName*. But sometimes wildcards can select more than what you want and you have to stop and think about it.

Well, it bothered me for quite some time. Until today. I always wondered: wouldn’t it be nice if git enumerated the files in the git status output and I could just use its number in other commands I’d like to use next?

The solution

The way I solved this problem involved three steps:

First: Format git status output to make it easily processable. Luckily, git status already has an option that fits the bill: –short.

As I said before, I also wanted numbers. Luckily again, in most unixes we have nl which does just that. This way, we can boost git status using –short and nl and get a nice and clean output like:

  1 /long path.../a 
  2 /long path.../b
  ...
  n /long path.../n

For this step, I added the following aliases to my .gitconfig:

  [alias]
    sn = !git status --short | nl -w 2
    s = !git status --short

 

Second: Extract the path of the file I want to use. Unix tools again make it easy to handle this task, with a little bit of cut and sed our goal can be achieved. I put this line of code in a script that I called gitl and added it to my $PATH:

  git s | cut -c4- | sed -n "$1p;$1q"

Third and final step: glueing things together. Ok, now I have a nice git status ouptut and I have gitl, how can them help me rollback the changes I’ve mistakenly done to file b?

  $ git sn

  1 /long path.../a
  2 /long path.../b
  ...

"Oh! I see, b is number 2". Let's rollback (using some unix command nesting):

  $ git reset HEAD $(gitl 2) 

It works! One more task achieved using only the keyboard. 
In case you've not noticed, you can use $(gitl 2) in any command you want.
Please leave a comment if you know another way to do it using only the command line.

Uncategorized

,

March 7, 2013

Leave a comment

Uma vida intencional

Há um bom tempo eu tenho a intenção de traduzir alguns posts que eu considero muito bons, principalmente sobre minimalismo, mais pra poder compartilhar com a galera que não acompanha tanto os sites lá fora. O meu blog favorito nessa linha é o Zen Habits e vou começar com um post recente do Leo Babauta sobre uma Vida Intencional (An Intentional Life). A tradução é livre:

Muitos de nós passamos os dias acordados, mas seguindo padrões desenvolvidos através dos anos. Nós nos movemos, fazendo coisas em casa, na Internet e no trabalho sem considerar muito o que estamos fazendo.

Contraste isto à ideia de uma Vida Intencional: em que tudo é feito com consciência, seguindo algum dos nossos valores fundamentais (compaixão, por exemplo). Tudo é feito de maneira intencional.

É verdade que muito do que fazemos possui uma intenção – Estou lavando a louça porque eu não quero uma casa bagunçada ou insetos na minha cozinha; Estou dirigindo para o trabalho porque preciso de um sustento; Levo meus filhos à escola porque eles precisam aprender. Contudo, após repetir essas ações todos os dias, as intenções meio que vão se apagando e no final mal nos lembramos delas. Nós encontramos uma motivação muito tempo atrás e não precisamos mais pensar sobre isso.

Mas e esse elas (as razões) tiverem mudado?

E se você estivesse alerta em relação às razões para as suas ações? Como isso transformaria as suas ações e a sua vida?

E se você lavasse a louça, mas antes se lembrasse de que está fazendo isto como um serviço a sua família, para os deixar feliz e como uma forma de meditação, realizando uma prática totalmente consciente (mindfulness)? Lavar a louça de repente se tornaria algo muito mais importante e deixaria de ser entediante.

A única diferença é a intenção.

E se dirigir para o trabalho fosse feito após uma declaração mental de que você está indo ajudar os seus colegas de trabalho, tornando-os mais felizes, encontrando assim satisfação através do trabalho? A direção seria muito mais feliz e você estaria bem menos propenso a ficar irritado quando alguém inevitavelmente te fechasse no trânsito.

Isto é Viver Intencionalmente.

Eu pratico isto em pequenas porções, não o tempo todo, mas de maneira progressiva. Quando eu o faço, a minha vida é diferente. Ela tem mais sentido, é vivida de forma mais consciente e eu fico mais contente com qualquer ação.

Uma prática simples de intenção: antes de realizar a sua próxima ação, online ou no trabalho, faça uma pausa, feche os seus olhos e diga mentalmente a sua intenção. Por que você vai fazer isso? É por compaixão aos outros ou por você mesmo? É para melhorar o mundo? É por gratidão ao trabalho e gentileza dos outros?

E então, conforme você realiza a ação, seja consciente do seu propósito.

Este é um pequeno passo. Mas naqueles breves momentos você está vivendo a vida intencionalmente.

Durante a tradução eu ouvi o http://rainfor.me, muito bom!

Uncategorized

, ,

August 17, 2012

4 Comments

Faculdade? Tô fora! Ou não

Uma pergunta que deve ser respondida por quase todo mundo a partir dos 17 anos (no Brasil) é “Devo ou não devo fazer faculdade?”. Alguns anos atrás era “Qual faculdade devo fazer?”, mas hoje acredito que já temos algumas almas iluminadas que são capazes de se perguntar se é uma boa mesmo fazer ou não uma faculdade. Além disso, está super na moda falar que faculdade é totalmente dispensável, que é #old e que não sei o que mais, que o Steve Jobs, o Zuckerberg e outros caras ricos e #cool são dropouts, então eu também devo ser, certo?

O James Altucher, que é um dos meus ídolos, diz que não você não precisa fazer uma faculdade logo de cara mesmo se quiser seguir carreira em áreas tradicionais como direito e medicina [1] [2] [3] e ele tem vários ótimos motivos para dizer isso. Se você está preocupado com esse tipo de coisa, a leitura é obrigatória mesmo para um brasileiro.

Além de pessoas famosas e milionárias como o James, várias pessoas têm opniões sobre para esse assunto, principalmente na área de TI. Um deles é amigo meu e vive batendo nessa tecla. Eu já passei por quase todo o espectro da questão: não tive faculdade, fiz faculdade, fiz mestrado (4 longos anos), defendi a faculdade, defendi não fazer faculdade e agora tenho uma opnião intermediária.

Primeiramente, quero ressaltar que quando falo de faculdade estou falando de uma boa faculdade, que não seja do tipo pagou-passou. Dito isso, porque valeria a pena gastar 4-5 anos indo à uma faculdade?

Você tem um objetivo

Por mais difícil que seja para alguns aceitar isso, muita gente simplesmente não consegue fazer as coisas se não tiver um objetivo. Algum procrastinador por aqui?

Você tem uma trilha bem definida

Ok, você é O cara auto motivado e com foco. Contudo, qual vai ser o seu foco? Você conhece todas as opções? Você vai abrir o browser, digitar http://www.google.com e buscar o que? Quais são as skills necessárias para ser um bom programador? Será que é só digitar código que compila? Você quer programar o que? Quer fazer sites ou quer fazer parte do time da curiosity?

Aqui quero fazer uma analogia. Por que é interessante ler um livro sobre um tema técnico? Porque você tem uma visão ampla do tema. É óbvio que a prática é importante, mas você vai basear toda a sua formação em apenas buscar soluções para o seu problema atual? O mesmo pode ser dito sobre uma faculdade. Será que ter uma noção mais ampla sobre o seu campo, sobre diferentes formas de resolver problemas e, principalmente, sobre como os outros fizeram antes não vai te agregar nada?

Deliberate Practice

Pra aprender a construir programas você precisa de muita prática sem propósito. Em uma empresa, você sempre vai ter a pressão de entregar algo no final do dia.

Nem todos somos bons autodidatas

Legal, tem um monte de caras que simplesmente lêem livros, tutoriais e códigos dos outros no github (!) e magicamente saem criando programas perfeitos que vão ser o próximo Facebook. Só peço que você tenha os pés no chão e saiba se realmente é um desses caras. E se não for, também não tem problema, o mercado está carente de profissionais “normais” que precisam de algum tempo e um pouco de base teórica para poder amadurecer.

A faculdade não é garantia de sucesso

Assim como não fazer faculdade também não é! Há vários exemplos de pessoas que fizeram faculdade e hoje estão em monkey jobs? Garanto que tem muita gente que não fez, entrou na área, se lascou e hoje não está mais no campo. E os casos de sucesso? Fazer sucesso sem ter formação dá notícia e todo mundo gosta de falar sobre isso. Mas e os milhares de casos de sucesso de quem fez faculdade? Não é tão legal falar, né?

Google began in January 1996 as a research project by Larry Page and Sergey Brin when they were both PhD students at Stanford University in California.

~ Wikipedia

 

Não sou um defensor ferrenho da educação formal, principalmente hoje em dia com courseras, udacities e khan academies florescendo com tanta força, acho que as coisas estão prestes a mudar bastante. Só queria que esse hype de “você não deve fazer faculdade” passasse logo. Grande parte dos grandes avanços da computação até hoje foram feitos por gente da academia, e é duro ver essa depreciação tão fácil por causa das pagou-passou.

Pra finalizar, quero lembrar que você pode praticar enquanto faz a faculdade. Quero lembrar que há sim algumas poucas empresas legais no mercado, que têm um ambiente legal, mas nem sempre têm um propósito nobre. Não vou fugir do clichê: você quer mesmo fazer parte da mais nova empresa super cool que no final das contas só tem mais um produto pra fazer as pessoas clicarem em propaganda? Você vai chegar no final e dizer o quê? Lembre-se que há muita pesquisa legal sendo feita na academia e com muito mais liberdade, com propósitos mais nobres e sem ter que gerar lucro no final do dia.

Meus dois centavos :)

[1] http://www.amazon.com/Was-Blind-But-Now-See/dp/1466347953

[2] http://www.jamesaltucher.com/2011/01/8-alternatives-to-college/

[3] http://www.huffingtonpost.com/james-altucher/dont-send-your-kids-to-co_b_409900.html

Uncategorized

August 8, 2012

Leave a comment

Estimar ou não estimar?

Por um acaso hoje eu esbarrei com o seguinte post: 5 Reasons Why You Should Stop Estimating User Stories. O texto fornece as seguintes razões para pararmos de estimar estórias (traduzi os tópicos e baguncei as explicações):

  1. Você economiza o tempo que gastaria fazendo as estimativas. Pelo que tenho lido, isso pode levar um bom tempo dependendo do tamanho da equipe e da predisposição para argumentações (em um Planning Poker, por exemplo).
  2. Você não vai precisar explicar para a gerência porque, no final das contas, acabou levando tanto tempo. Quando uma deadline não é cumprida, o time pode entrar em um modo defensivo, afinal, “você disse que ia entregar no final do mês!”. Com o passar do tempo, isso pode levar as pessoas a se preocupar mais com as deadlines do que com a qualidade ou com a busca de soluções melhores.
  3. Você não faz promessas difíceis de cumprir. Nós costumamos ser otimistas ou, pior ainda, podemos nos sentir pressionados a fornecer estimativas otimistas por não querer ficar pra trás dos colegas ou ficar mal na foto com a gerência.
  4. Você não adiciona mais pressão ao time. Em alguns casos, estimativa significa uma deadline.
  5. Você foca nas coisas realmente importantes. Você adiciona outro fator à balança na hora de priorizar o que será feito. Na hora de planejar a iteração o mais importante a ser feito é o que agrega mais valor e não o que tem estimativas mais interessantes, certo?

Imagino que algumas pessoas possam ficar de cabelo em pé com essa proposta. Mas será que ela é tão surreal assim? Alguns podem logo de cara se lembrar de Lei de Parkinson:

“O trabalho se expande para preencher o tempo disponível para a sua realização”

E nesse caso, quando o tempo disponível é infinito? This is madness! Por mera coincidência, ainda ontem estava lendo o PeopleWare e quero compartilhar mais um pouco do que li com vocês para refletirmos juntos sobre a questão.

Primeiro, é preciso ficar claro que a Lei de Parkinson, apesar de vários gerentes não saberem disso, não é uma lei, é uma piada, que só pegou por tem um fundinho de verdade. É claro que todo gerente tem uma estória pra contar de um funcionário que fazia corpo mole se não estivesse sob pressão. Contudo, em um ambiente de trabalho sadio, as razões para que algumas pessoas não tenham o desempenho esperado geralmente são: falta de competência, falta de confiança ou falta de identificação com o resto do time ou com os objetivos do projeto. Mais pressão não irá ajudar em nenhuma dessas situações. Tratar o time como trabalhadores Parkinsonianos não irá funcionar.

Pra fechar, em 1985 alguns estudos foram conduzidos por Jeffery-Lawrence investigando a produtividade (a la CoCoMo) de vários projetos, vou resumir os resultados. Primeiramente, os projetos foram separados em três grupos:

  1. as estimativas eram feitas pelo programador
  2. as estimativas eram feitas pelo supervisor (gerente)
  3. as estimativas eram feitas pelo programador e supervisor juntos

E os resultados:

Estimado por Produtividade (média) Número de projetos estudados
Programador 8.0 19
Supervisor 6.6 23
Programador & supervisor 7.8 16

Opa, parece que o negócio é deixar o programador estimar o que vai fazer então, certo? Não tão cedo. Os pesquisadores então resolveram investigar outros projetos em que as estimativas eram feitas por um analista (Systems Analysts):

Estimado por Produtividade (média) Número de projetos estudados
Programador 8.0 19
Supervisor 6.6 23
Programador & supervisor 7.8 16
Analista 9.5 21

O analista, de acordo com artigo, conhecia o processo em mais detalhes e não era afetado pelo otimismo da pessoa que, de fato, ia realizar o trabalho ou das pressões políticas e de orçamento que afetavam o supervisor. Além disso, como fazia parte do trabalho do analista estimar, ele tinha muito mais experiência com estimativas do que os anteriores.

Por fim (em relação aos estudos), os pesquisadores investigaram 24 projetos que decidiram não estimar (“Just wake me up when you’re done.”) as tarefas:

Estimado por Produtividade (média) Número de projetos estudados
Programador 8.0 19
Supervisor 6.6 23
Programador & supervisor 7.8 16
Analista 9.5 21
Sem estimativas 12.0 24

Essas pesquisas não provam nada, mas servem para questionarmos o status-quo, não?

Pra fechar quero deixar mais um trecho do Peopleware:

Estimativas mal feitas, estimativas sem esperanças de ser cumpridas, sugam toda a energia do programador. Capers Jones, conhecido por seus estudos sobre métricas coloca dessa forma: “Quando a agenda do projeto é totalmente irracional e irreal a ponto de que nenhuma quantidade de horas-extras farão cumprí-la, o time se torna frustrado e aborrecido e a moral vai parar lá embaixo”. Não importa muito se o “irracional e irreal” vêm do chefe ou dos próprios desenvolvedores. As pessoas simplesmente não trabalham efetivamente quando estão presas em um situação em que não se pode ganhar (no-win situation).

Tá Zé, isso tudo é muito interessante, mas ainda não estou convencido. Blz. Antes de tudo, divirta-se com isso. Deu umas risadas? Ok, agora leia então o Agile Estimating and Planning e aprenda o real papel de estimativas por pontos e velocidade. O que eu posso dizer é que trabalho sem estimativas há vários meses e não sofro mais dos problemas apresentados no início do texto e, intuitivamente, posso dizer que realmente aumentei um pouco a minha produtividade.

Update 18/04/12 : Você devia dar uma olhada nesses bias que a gente tem na hora de estimar também: Why you suck at estimating.

Update 20/04/12: Uncle Bob escreveu hoje sobre “Porque estimar é tão difícil“.

Update 02/06/12: Joel Semeniuk apresenta “Você quer melhores estimativas? Então pare de estimar!“. Nessa apresentação o Joel fala sobre as “5 Estimation Laws” e também sobre alguns anti-patterns.

Update 08/02/13: Ron Jefrries escreve na Pragmatic Magazine “Estimation is Evil“. Pare de estimar e comece a entregar

Update 09/03/13: Agora foi a vez de Martin Fowler tomar uma posição em PurposeOfEstimation.

Uncategorized

March 15, 2012

Leave a comment

Book Review: The Mythical Man-Month (MM-M)

During the last month I’ve been reading the quoted-often-but-followed-rarely Mythical Man-Month. What a nice book!

Fred Brooks starts the book talking about the programming art. Why is it fun, after all? He points many reasons and, among them, the joy of always learning. I totally agree with him, and if you don’t like it, please stop working as a programmer.

The book is just great. Despite my own fault of reading it only now, when I’m 26 and after graduating I got shocked by the unpopularity of the book here in Brazil. At my workplace, with 70 programmers I’m almost sure that nobody has read it (including the bosses), insane!

Why is the book special? Man, almost all those things you hear agilists talk about were first written in the MM-M! For example, about documentation:

“As a principal objective, we must attempt to minimize the burden of documentation, the burden neither we nor our predecessors have been able to bear successfully. An approach. The first notion is to use the parts of the program that have to be there anyway…”

It’s impressive how this guy was able to figure out all those problems in the software production field and, still better, propose solutions! It’s impressive how he was able to write a book so clear in 1975, when the field was in its early infancy (I believe it’s still in the infancy).

Obviously, there are one or two chapters which are no longer relevant and some predictions which did not come true, but the book as a whole is invaluable. I’ve read the anniversary edition, and if you have access to it, I would recommend that you first read the last chapter, in which Brooks gives a retrospective of all the “mistakes” made in the first edition.

Finally, out of the almost 300 pages, I’ve got 95 notes and marks on my kindle. An average of 1 note for each 3 pages is quite impressive for a book from 1975, isn’t it? So, if you still wonder if the book is worth your time, have no doubts from now on.

Uncategorized

,

September 24, 2011

Leave a comment

« Older posts
Follow

Get every new post delivered to your Inbox.