Como começar uma StartUp

Boa noite,

   essa será minha última publicação no blog da disciplina, por esse motivo me darei a liberdade de fugir do assunto principal, os sistemas de controle de versões, e irei abordar um infográfico da RecepeTI, que explica os passos para se criar uma StartUp de sucesso.

   O sonho de todo estudante de informática na atualidade é concluir seu curso, ou antes disso, e abrir uma empresa de sucesso, que lhe renderá milhões com um aplicativo inovador de smartphone, mas como fazer isso?

   A RecepeTI (Rede Catarinense de Inovação) lançou, em março de 2015, um infográfico listando o caminho "simples" é necessário ser trilhado para conseguir o sucesso da sua startup.

Fonte: http://recepeti.org.br/wp-content/uploads/2015/03/info_startup.png

   O trabalho tem início com algumas orientações de perfil do estudante, viva no futuro e observe o que falta no mundo, com isso escreva e ressalte suas idéias. Para as idéias que valem a pena faça um protótipo. Mostre-o para cem pessoas e teste para que ele faça algum sentido.

   Feito esses passos chegou a hora de ganhar dinheiro com isso, em primeiro lugar encontre um parceiro e constitua uma empresa formal, agora é só procurar um financiamento para que você possa impulsionar sua empresa.

   Com a empresa possuindo clientes monitore sua fidelização, se não estiverem satisfeitos lance novos produtos, caso já estejam satisfeitos alcance mil usuários.

   Tendo clientes e ganhando dinheiro, chegou a hora de continuar crescendo, mostre ser possível crescer cinco porcento semanais e permaneça assim pelo próximo quatro anos até chegar ao SUCESSO!!!

   Com essas dicas chegou a hora de colocarmos em prática nossos sonhos e lançarmos o próximo "WhatsApp" ou o "Waze".

Fonte: http://recepeti.org.br

GitHub - Como utilizar

Boa noite,

   nessa postagem iremos ver um vídeo do HxTutors que está disponível no YouTube, explicando um pouco para que serve o GitHub e como usar. O vídeo não é longo e explica passo a passo de como utilizar, espero que possa ajudar a quem esteja iniciando.

Fonte: https://www.youtube.com/watch?v=neDiLHwXSVo

Bitbucket

Boa noite,

   nessa postagem iremos falar do Bitbucket, um repositório gratuitamente para projetos em GIT ou Mercurial.

   Esses repositórios são interessantes para os usuários que possuem algum projeto pessoal que queria ter acesso de outros lugares ou trabalhar colaborativamente sem ter um custo adicional. Além de permitir que o usuário possa aprender a utilizar novas ferramentas de gerência de projetos e versionamento.

Fonte: https://s3.amazonaws.com/helpjuice_production/uploads/upload/image/2341/29865/bitbucket.png

   O Bitbucket é um repositório de controles de versões, mantido pela empresa Atlassian, apresentando algumas vantagens como, integração com o JIRA, cliente desktop, visões entre outras coisas, o que deixa seu código mais rápido e inteligente.

   Possui duas modalidades de preço, o Small Teams, que é gratuito para até cinco usuários no projeto, e o Growing Teams, que permite dez, vinte e cinco, cinquenta e cem usuários, cada um tendo um custo mensal de um dólar, a outra modalidade do Growing Temans oferece a opção de usuários ilimitados a um custo mensal de duzentos dólares.

Fonte: https://bitbucket.org

Plano de Projeto de Software

Plano de Projeto para o Sistema de Controle de Frequência:

Plano de Projeto de Software from Matheus Mendonça

Qual a melhor ferramenta de controle de versão: Subversion, Git ou Mercurial?

Bom dia a todos,

Como já muito apresentado por nós aqui no blog, existem dois tipos de controle de versão: centralizado e o distribuído. O modelo distribuído é mais recente e possui algumas vantagens interessantes sobre o centralizado, embora seja um pouco mais complexo. Para as equipes que decidiram migrar para o distribuído ou mesmo permanecer com o centralizado, ainda resta a questão de qual a melhor ferramenta escolher.

Para aqueles que vão ficar no controle de versão centralizado, a decisão é bem simples: Subversion. Já é um padrão estabelecido, desbancando outros tais como CVS, Visual Source Safe, ClearCase etc. Não há realmente muito a acrescentar neste ponto.

O verdadeiro desafio está na escolha da ferramenta de controle de versão distribuído.

Filtragem Inicial

Existem muitas ferramentas de controle de versão distribuído. Para diminuir esse número inicial, vamos usar alguns critérios de filtragem inicial:

1. Licença open source. Não há a menor necessidade de usar uma ferramenta proprietária para controle de versão. Aliás, as melhores são open source.
2. Rodar em plataformas diferentes (Windows, Linux, etc.). A mesma ferramenta deve permitir que a equipe use a plataforma que quiser/precisar para trabalhar. Melhor ainda se houver uma interface gráfica tipo TortoiseSVN ou plugin para a IDE, mesmo que a linha de comando seja muito mais rápida e produtiva para a maioria das operações do controle de versão.
3. Massa crítica de projetos já usando. Se vários projetos grandes usam a ferramenta é sinal de que ela já foi testada, avaliada e aceita por outros antes. Além disso, é mais provável que haverá uma comunidade ativa mantendo e desenvolvendo a ferramenta por muitos anos.

Depois de aplicados os critérios na lista, acabam restando praticamente o Git e o Mercurial. Talvez o Bazaar também pudesse ser incluído mas outros como Darcs, Monotone e SVK não passam no critério 3.

A seguir, alguns projetos conhecidos que usam o Mercurial ou o Git:

• Mercurial: Google Code, Python, Java (OpenJDK), Mozilla, Netbeans (IDE), OpenSolaris  etc.
• Git: Linux kernel, Perl, Samba, X.org Server, Qt, Ruby on Rails,  GNOME, Google Android, Btrfs da Oracle etc.

Aspectos Sociais na Escolha do DVCS

Critérios de desempate podem ser desempenho, funcionalidades, facilidade de uso, portabilidade, interfaces etc. O problema é que as análises comparativas entre o Mercurial e o Git têm mostrado muito mais semelhanças que diferenças entre os dois. Embora um ou outro tenha uma pequena vantagem em algum dos aspectos, não há diferença realmente significativa que justifique uma decisão baseado nisso.

Processos recentes tem usado outros fatores para o desempate tais como menor curva de aprendizado, suporte à plataforma Windows e preferência dos desenvolvedores para definir a escolha:

1. A análise comparativa feita pelo Google Code entre o Mercurial e o Git considerou as duas alternativas bastante equilibradas. O Mercurial foi escolhido por ter um conjunto de comandos mais próximos do Subversion, o que facilita a transição dos desenvolvedores, e também por ter desempenho e adequação melhores ao serviço que o Google Code já oferece.
2. Outro exemplo é o processo que levou o Python a também adotar o Mercurial (PEP 374 – Chosing a distributed VCS for the Python project). A análise comparativa entre Mercurial, Bazaar e Git apresentou alguns casos de uso, comparações de desempenho etc. mas, no final, o que pesou bastante foi o melhor suporte ao Windows, a preferência da comunidade de desenvolvedores pelo Mercurial e, é claro, o fato de o Mercurial ser escrito em Python.

Considerando funcionalidades e desempenho equivalentes, o que vai ser importante na escolha são as afinidades do Git ou Mercurial com as características do projeto/equipe/empresa. O desempate acabará sendo feito por critérios mais subjetivos tais como proximidade com outros projetos relacionados e preferência dos desenvolvedores.

Fonte: http://pronus.eng.br/blog/http:/pronus.eng.br/blog/qual-a-melhor-ferramenta-de-controle-de-versao-subversion-git-ou-mercurial

Apresentação do Seminário

Segue link do Dropbox, de onde pode ser baixada/visualizada nossa apresentação do seminário.

Apresentação em PDF

Vantagens e Desvantagens do Controle de Versão Distribuído

Controle de versão distribuído (Distributed Version Control Systems – DVCS) é a mais nova geração de sistemas de controle de versão de software. Apesar de o conceito existir já há algum tempo, recentemente as ferramentas se tornaram maduras o suficiente para chamar a atenção de diversos projetos open source, que migraram ou expandiram seu suporte do Subversion (centralizado) para o Mercurial, Git e Bazaar (distribuídos) por exemplo.

Benefícios do Controle de Versão Distribuído

As vantagens estão relacionadas à distribuição do processamento, redundância/replicação de repositórios e as novas possibilidades de colaboração entre desenvolvedores.

Do ponto de vista do desenvolvedor

• Rapidez. As operações são processadas localmente. Não é necessário passar pela rede e contatar o servidor central para fazer um commit, log ou diff por exemplo.
• Autonomia. A conexão com a rede só é necessária para trocar revisões com outros repositórios. Fora isso, trabalha-se desconectado e em qualquer lugar, como num cliente por exemplo.
• Ramos privados. Além de um repositório próprio, o trabalho local é feito em um ramo privado que não interfere, nem sofre interferência dos demais, mesmo nas operações de sincronização entre repositórios. O momento de combinar um ramo com outro é uma decisão do desenvolvedor e não obrigatório antes de cada commit, como acontece no centralizado.
• Facilidade de Mesclagem. Só a facilidade de criação de ramos não seria suficiente se não fosse o rastreamento automático usado pelos DVCS, que torna o processo de mesclagem muito mais simples e indolor. Observação: No Subversion, o rastreamento automático de merges começou a partir da versão 1.5

Do ponto de vista da gerência/coordenação

Parte das decisões gerenciais envolve manter livre o caminho da equipe para que possam trabalhar da melhor maneira possível. Outras decisões importantes são sobre redução de custos. Nestes dois casos específicos, o modelo distribuído oferece as seguintes vantagens:

• Confiabilidade. No sistema centralizado, uma pane no servidor interrompe todo o desenvolvimento. Já no sistema distribuído, além de a equipe poder continuar seu trabalho (observação: veja a seção “controle de mudança ainda é centralizado” mais abaixo), os repositórios dos desenvolvedores funcionam como cópias de backup de todo o projeto.
• Redução de custos com servidor. A carga de processamento fica distribuída nas próprias máquinas dos desenvolvedores. O repositório “central”, quando existe, tem o papel do repositório “oficial” e não como processador central das requisições.

Em que situações o controle de versão distribuído não vai tão bem?

Nem tudo são flores com o modelo distribuído de controle de versão.

Maior complexidade

No centralizado, os desenvolvedores trabalham no mesmo ramo, seja esse ramo o principal ou um ramo de manutenção.

Essa forma de trabalho é mais simples de se entender. Mesmo que limitadamente, uma pessoa com pouco conhecimento de controle de versão consegue trabalhar com o resto da equipe.

O modelo distribuído é mais complicado. A arquitetura peer-to-peer, ramos privados e as mesclagens aparentemente desordenadas podem tornar o grafo da evolução do projeto confuso à primeira vista.

Ao contrário do centralizado, não adianta só commit e update para funcionar “no tranco”. Todos os desenvolvedores da equipe precisam ter um conhecimento maior do modelo, da ferramenta e, de preferência, também de um processo de desenvolvimento que padronize fluxos de trabalho a serem seguidos. Só assim, o grafo acima deixa de ser apenas um emaranhado e passa a representar muito claramente o fluxo do trabalho.

Resumo das Características do Controle de Versão Distribuído

Referências:

1. Conceitos Básicos de Controle de Versão Centralizado e Distribuído
2. Distributed Revision Control