Busca

JSantanna

Meu blog sobre engenharia, tecnologia, ciência da Computação, etc.

Categoria

programação

10 regras de programação da NASA ( em inglês)

NASA’s 10 rules for writing mission-critical code:

  1. Restrict all code to very simple control flow constructs – do not use goto statements, setjmp or longjmp constructs, and direct or indirect recursion.
  2. All loops must have a fixed upper-bound. It must be trivially possible for a checking tool to prove statically that a preset upper-bound on the number of iterations of a loop cannot be exceeded. If the loop-bound cannot be proven statically, the rule is considered violated.
  3. Do not use dynamic memory allocation after initialization.
  4. No function should be longer than what can be printed on a single sheet of paper in a standard reference format with one line per statement and one line per declaration. Typically, this means no more than about 60 lines of code per function.
  5. The assertion density of the code should average to a minimum of two assertions per function. Assertions are used to check for anomalous conditions that should never happen in real-life executions. Assertions must always be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken, e.g., by returning an error condition to the caller of the function that executes the failing assertion. Any assertion for which a static checking tool can prove that it can never fail or never hold violates this rule (I.e., it is not possible to satisfy the rule by adding unhelpful “assert(true)” statements).
  6. Data objects must be declared at the smallest possible level of scope.
  7. The return value of non-void functions must be checked by each calling function, and the validity of parameters must be checked inside each function.
  8. The use of the preprocessor must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed. All macros must expand into complete syntactic units. The use of conditional compilation directives is often also dubious, but cannot always be avoided. This means that there should rarely be justification for more than one or two conditional compilation directives even in large software development efforts, beyond the standard boilerplate that avoids multiple inclusion of the same header file. Each such use should be flagged by a tool-based checker and justified in the code.
  9. The use of pointers should be restricted. Specifically, no more than one level of dereferencing is allowed. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. Function pointers are not permitted.
  10. All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. All code must compile with these setting without any warnings. All code must be checked daily with at least one, but preferably more than one, state-of-the-art static source code analyzer and should pass the analyses with zero warnings.

About these rules, here’s what NASA has to say:

The rules act like the seat-belt in your car: initially they are perhaps a little uncomfortable, but after a while their use becomes second-nature and not using them becomes unimaginable.

Anúncios

Biblioteca para usar o gnuPlot a partir de um programa em C

gnuplot_demo
Exemplo de um gráfico feito pelo gnuplot.

Para quem pensa em usar o gnuplot( programa para gerar gráficos matemáticos) a partir de programas em C, achei essa biblioteca bem interessante, ainda não testei mas não deve ser complicado de utilizar.

Só um aviso, essa biblioteca funciona em Sistemas Operacionais com o padrão POSIX ( Unix, Linux, MacOS) , para quem usa o windows , tem que baixar um compilador que de suporte, de um pulo no link que tem mais informações por lá.

http://ndevilla.free.fr/gnuplot/

Alunos da USP criam sistema que corrige exercícios de programação em segundos

Agência FAPESP – Dois alunos do Instituto de Ciências Matemáticas e de Computação (ICMC) da tumblr_inline_nlzbxf19OT1r1azxg_400Universidade de São Paulo (USP), em São Carlos, Felipe Duarte e Fábio Sikansi, criaram um sistema de submissão e correção automática de trabalhos de programação denominado Run.codes.
A ferramenta possibilita que os estudantes cadastrem on-line os trabalhos de programação realizados e aguardem alguns segundos até que o resultado da correção apareça. “Nossa ideia foi fazer um sistema eficaz para que o professor pudesse gerir efetivamente o trabalho realizado em uma sala de aula”, explicou Duarte, doutorando do ICMC.
Com o Run.codes, o tempo médio de correção para um trabalho considerado extenso gira em torno dos 30 segundos. “O tempo de correção é muito menor e o sistema ainda permite que o professor abra o código do estudante e verifique o que ele errou”, avalia Moacir Ponti Júnior, professor do ICMC, que utilizou o sistema no semestre passado nas disciplinas Programação orientada a objetos e Introdução à ciência da computação II.

Continuar lendo “Alunos da USP criam sistema que corrige exercícios de programação em segundos”

Meu kit de desenvolvimento de software do dia a dia

Conjunto de 10 ferramentas do dia a dia , as que mais utilizo para desenvolvimento de software, ainda tem outras mas essa pequena lista já é bem representativa  🙂 , se você tem outras sugestões de aplicativos comente no post .

1 – Java 
Principal linguagem que utilizo( vocês já devem ter percebido pelos posts : -)  ) , apresar de vez em quando usar o C/C++ , bash e mais recentemente o ruby …

Java SE – Downloads | Oracle Technology Network | Oracle

2 – IDE : Netbeans 

Pra mim ainda é a mais completa apresar de reconhecer que o eclipse em muitas maquinas roda bem mais rápido , prefiro o netbeans pelo conjunto de ferramentas integradas, e no geral não preciso configurar nada , estou ficando preguiçoso de ter que mexer , configurar e fuçar tutoriais para que as coisas funcionem … em fim , vou de Netbeans .

Welcome to NetBeans Continuar lendo “Meu kit de desenvolvimento de software do dia a dia”

10 coisas que todo desenvolvedor web deve saber

Entrar na área do desenvolvimento web por conta própria pode ser um grande desafio, daqueles que exigem que você tente, falhe, repense e tente novamente antes de finalmente chegar ao ponto desejado.

Mas saber de algumas coisas antes de começar na área pode tornar a experiência do aprendizado um pouco menos “traumática”, como afirmou no Quora o desenvolvedor web Avi Flombaum.

O especialista autodidata também é professor e fundador da escola de programação Flatiron School, nos EUA, e deu dez dicas relacionadas ao tema como resposta à pergunta “O que desenvolvedores web autodidatas gostariam de já saber antes de ter começado?”.

A dúvida, como
dá para ver, é mais voltada para o desenvolvimento web, mas algumas das sugestões podem muito bem servir para outros campos. Confira a seguir:

1. “Aprender a trabalhar com outros desenvolvedores é muito importante”

O primeiro ponto levantado por Flombaum é o trabalho em equipe. “Quando você é autodidata, precisa passar muito tempo trabalhando sozinho”, escreveu.

“Mas é absolutamente essencial que você aprenda a trabalhar com outros desenvolvedores.”

E o especialista não fala apenas de comunicação, mas também de divisão de projetos, que precisa ser feita de forma correta.

“Três desenvolvedores trabalhando juntos de uma vez sempre vão ser mais rápidos mesmo do que o melhor desenvolvedor trabalhando sozinho.”

2. “Saber como as coisas funcionam é diferente de saber como usá-las”

A dica faz referência aos muitos padrões e arquiteturas envolvidos no processo de desenvolvimento.

Flombaum afirma que, ao começar o processo de aprender sozinho, você tem duas opções de como se relacionar com essa infinidade: pode ignorar tudo ou pode usar as coisas que forem necessárias mesmo “sem saber como elas funcionam ou por que existem”.

Mas fugir dessa regra e aprender mais sobre os padrões e arquiteturas que você pretende usar pode poupar um bom tempo no fim das contas.

3. “Não tenha medo de falar com os outros”

Saia e “converse com os programadores que você admira”, escreve o especialista da Flatiron School. Vá às conferências e faça como ele, parando para conversar com outros profissionais da área.

O professor afirma que essas abordagens o colocaram em contato com desenvolvedores do porte de Yehuda Katz e Ilyia Grigorik, e também o ajudaram a receber feedback da comunidade e colaboraram com seu aprendizado.

4. “Seja seus heróis”

Flombaum também recomenda que todos “imitem” desenvolvedores que admiram, algo que ele não se arrepende de ter feito.

“Ele tentaram escrever um livro? Eu vou tentar escrever um livro. Eles escreveram uma biblioteca? Eu vou tentar escrever uma biblioteca”, afirmou.

Mesmo que nenhuma das experiências tenha sido bem sucedida, serviram como um bom aprendizado “para ser um profissional”.

5. “Leia os livros, mesmo que você não os entenda”

“Se você vai fazer parte de uma discussão e da comunidade, deveria tentar saber do que você está falando”, escreveu o especialista.

A ideia é que, ainda que você não entenda o que está lendo, ao menos algo será extraído da experiência – mesmo que esse algo sejam apenas os nomes dos principais autores da área.

Flombaum ainda indica algumas obras para começar, como “Learn to Program”, de Chris Pine, e“Weaving the Web”, do patrono da rede Tim Berners-Lee – ambos em inglês, e sendo este último bom para contextualizar.

6. “A aparência do código conta”

Há quem discorde, mas o professor garante: “A forma como seu código é lido e visto pelos outros é algo muito importante”.

Para garantir tudo isso, é bom não deixar nada quebrado, “nomear corretamente suas variáveis”, “ter nomes de métodos que batem com o estilo e a sintaxe das linguagens”, entre outros pontos.

Flombaum também é um pouco radical quanto à presença de comentários, algo que ele pareceu tolerar apenas em quantidade razoável e que não deve ser usado como “muleta”, nas palavras dele.

7. “É melhor ser competente em algo do que um expert em nada”

“Nada substitui os básicos”, escreveu Flombaum, para depois afirmar que iniciantes não devem dar prioridade às ferramentas “da moda”.

O ponto depois é reforçado por outro programador, Michael Soileau, que disse: “Fique bom em JavaScript, depois melhore em JQuery, CoffeeScript e outros frameworks. Fique bom em PHP, para só então aprender como o WordPress o influencia. Melhore em Rails, e depois veja como as pedras preciosas [Ruby, no caso] tornam as coisas mais fáceis”.

O ideal, concordam os dois, é que os desenvolvedores web que estão começando deem prioridade às linguagens que melhor se encaixam em seus objetivos.

8. “Aprender a desenvolver não é algo que acontece de uma vez”

O professor da Flatiron School compara a curva de aprendizado na área de desenvolvimento web a um S – ou seja, algo que está longe de ser constante.

É bem provável que você vá ficar travado em um ponto, para só depois voltar a crescer em termos de aprender coisas novas.

“Você só precisa ser aplicado ao encarar esses percalços, porque é algo que vai acontecer frequentemente na sua carreira”, afirmou.

“Lembre-se de que, se você continuar, eventualmente tudo vai acabar fazendo sentido.”

9. “Ruby pode ser um bom lugar para começar”

E isso “mesmo que a linguagem não importante muito para um desenvolvedor iniciante”, escreve ele.

É um ponto polêmico, mas é mais uma preferência de Flamboum mesmo, que se diz admirador da ideia por trás do Ruby, uma linguagem criada “para fazer os desenvolvedores felizes”.

Se estiver interessado, vale checar a página oficial, que tem alguns tutoriais.

10. “Apaixone-se pelo trabalho”

Por fim, o mais importante, visto que não dá para ir muito longe sem gostar do que faz.

“É difícil passar pelas partes difíceis sem amar a profissão”, escreve o especialista, para depois levantar alguns pontos positivos da área, dizendo o quanto as criações de desenvolvedores podem acabar impactando tudo – e que você pode fazer parte disso.

fonte : Exame-Abril

1000 projetos práticos para programadores iniciantes

Bom para quem já aprendeu uma linguagem e quer projetos para exercitar o que aprendeu

I have come up with a big list of beginner programming projects / programming tasks (Aggregated from many sources) from which you can choose your first…

Link do site: http://blog.programmersmotivation.com/2014/07/09/list-projects/

Melhores linguagens de programação ou Linguagens mais populares

O IEEE Spectrum montou um survey para pesquisar quais seriam as linguagens mais utilizadas pela comunidade de desenvolvimento de software. A pesquisa utilizou 10 fontes de informação para a pesquisa:

  • search results in Google 
  • data from Google Trends 
  • tweets sent on Twitter 
  • GitHub repositories 
  • StackOverflow questions 
  • Reddit posts 
  • Hacker News posts 
  • demand for jobs on the Career Builder job site 
  • demand for jobs on the Dice job site 
  • IEEE Xplore journal articles 

As linguagens forma categorizadas como: web, mobile, enterprise e embedded, veja o resultado abaixo:

IEEE Spectrum All Languages Top 20

  1. Java 
  2. C++ 
  3. Python 
  4. C# 
  5. PHP 
  6. JavaScript 
  7. Ruby 
  8. MATLAB 
  9. Perl 
  10. SQL 
  11. Assembly 
  12. HTML 
  13. Visual Basic 
  14. Objective-C 
  15. Scala 
  16. Shell 
  17. Arduino 
  18. Go
    image

    Source: IEEE Spectrum’s 2014 Ranking

    IEEE Spectrum Web Top 10

    1. Java 
    2. Python 
    3. C# 
    4. PHP 
    5. JavaScript 
    6. Ruby 
    7. Perl 
    8. HTML 
    9. Scala 
    10. Go 

    IEEE Spectrum Mobile Top 10

    1. Java 
    2. C++ 
    3. C# 
    4. JavaScript 
    5. Objective-C 
    6. Scala 
    7. Delphi 
    8. Scheme 
    9. ActionScript 

    Coisas estranhas

    Algumas coisas causam estranheza e discussão nessa pesquisa:
    Python é classificada como ‘web’ e ‘enterprise’ enquanto que PHP e Ruby são só ‘web’?
    Sim, HTML não é uma linguagem mas é classificada como apenas ‘web’ e de alguma forma ela vem depois de SQL, Perl e até mesmo Assembly?
    O C# mobile development fica realmente acima do uso de JavaScript e Objective-C? E quem anda criando “phone apps” in Scala, Delphi e Scheme?

    De qualquer maneira é um indicador centrado no mercado norte americano e com fonte baseada em uso acadêmico , é bom comparar esses resultados com o índice TIOBE.

    Fonte:Sitepoint

    Technology Radar

    Um serviço muito interessante para quem desenvolve software, essa ferramenta lista utilizando 4 classes de interesse o que mais está sendo utilizado no momento em projetos e industrias de software, é muito bom dar uma olhada antes de se comprometer com horas de estudo em uma tecnologia, ferramenta ou linguagem nova, como você deve saber alguns projetos que inicialmente pareciam muito promissores acabam morrendo, se a comunidade de software livre ou a industria de software não abraçar a causa você corre o grande risco de perder seu tempo e ficar craque em uma ferramenta que miguem mais utiliza.

    As 4 classes monitoradas são:

    • Técnicas
    • Ferramentas
    • Plataformas
    • Linguagens e Frameworks
    O link do serviço Technology Rada é http://www.thoughtworks.com/radar/#/
    Vale a pena vez em quando visitar o serviço e verificar o que anda pintando de novo no mundo de desenvolvedores.

    Ruby Brasil – Aprendendo Ruby – Parte 0 – O inicio.

    Um curso introdutorio muito bom para quem quer começar no Ruby, vai do básico até a orientação a objetos , diferente de Java a tipagem em Ruby é dinâmica o que deixa o código mais enxuto, vale pelo menos a pena conhecer essa linguagem de programação que está crescendo muito no mercado. O curso é do site Ruby Brasil que por sinal é outra boa dica para quem está começando no Ruby.
    Aproveitando a dica recomendo a IDE Aptana Studio para quem quer começa a utilizar um bom edito de código para o Ruby , a ferramenta é gratuita e foi baseada no código da IDE Eclipse, enjoy !

    ‘via Blog this’

    Crie um website ou blog gratuito no WordPress.com.

    Acima ↑