6 Motivos para usar Node.js

Entenda nesse post as 6 vantagens sobre por que vale a pena estudar e usar Node.js

1. JavaScript everywhere: Com Node.js você vai trabalhar com JavaScript no server-side utilizando o runtime Google V8. Com isso você reduz e muito a curva de aprendizado, afinal será a mesma linguagem JavaScript do client-side, e nisso você vai manter um projeto fácil de dar manutenção (É claro! Desde que saiba JavaScript de verdade), vai achar profissionais rapidamente para colaborar em seus projetos, e vai gastar menos tempo estudando uma nova linguagem server-side para criar uma aplicação. Outra vantagem disso é que você não vai utilizar mais aqueles frameworks para serialização / deserialização de objetos JSON, afinal o JSON client-side é o mesmo JSON server-side, há também casos de aplicações usando banco de dados orientado a documentos (por exemplo: MongoDB ou CouchDB) e neste caso toda manipulação de dados é realizada através de objetos JSON também.
2. Non-Blocking IO: O Node.js trabalha com o modelo de IO não-bloqueante, ou seja, nenhuma tarefas pesadas de IO vai travar sua aplicação, pois elas serão executadas em background sem bloquear a aplicação e quando elas finalizarem você trata os resultados através dos callbacks das funções. Em uma aplicação de muita leitura de arquivos, o Node.js vai se destacar melhor nisso, pois vai ler os arquivos de forma assíncrona enquanto os demais processos da aplicação continuam rodando. Alguns exemplos práticos que geralmente travam aplicação são: manipulação de arquivos pesados, envio de emails e leitura de base de dados. Com IO não-bloqueante do Node.js essas tarefas são facilmente executadas em background e o retorno de sucesso ou falha dessas tarefas ocorrem através de uma função de callback.
3. Comunidade Ativa: Esse é um dos pontos mais fortes do Node.js. Existem várias comunidades no mundo inteiro trabalhando muito para popularizar o Node.js, seja divulgando posts e tutoriais, palestrando novidades e principalmente publicando e mantendo +70000 módulos no site NPM (Node Package Manager). Aqui no Brasil temos dois grupos bem ativos: Google Groups NodeBR e Facebook Node.js Brasil.
4. Ótimos salários: Os desenvolvedores de Node.js, geralmente recebem bons salários, isso ocorre pelo fato de que infelizmente no Brasil ainda existem poucas empresas adotando essa tecnologia. Isso faz com que empresas que necessitem dessa tecnologia paguem salários na média ou acima da média para manterem desenvolvedores que dominem Node.js, principalmente boas práticas JavaScript. Outro caso interessante também são as empresas que contratam estagiários e juniors que tenham ao menos conhecimentos básicos de JavaScript, com o objetivo de treiná-los para trabalhar com Node.js, neste caso não espere um alto salário e sim um amplo conhecimento preenchendo o seu currículo.
5. Ready for real-time: O Node.js ficou popular graças aos seus frameworks que interagem em real-time entre cliente e servidor. SockJS, Socket.IO, Engine.IO são alguns exemplos disso. Eles são compatíveis com o novo protocolo WebSockets e permitem trafegar dados através de uma única conexão bi-direcional, tratando as mensagens via eventos no JavaScript.
6. Big players usando: LinkedIn, Wallmart, Groupon, Microsoft e Paypal são algumas das empresas usando Node.js atualmente, e tem mais um monte de outras empresas e aplicações neste link.

fonte: http://udgwebdev.com/6-motivos-para-usar-nodejs/

Node.js para leigos

Bem-vindos ao cursinho de Node.js para leigos, neste primeiro post apresentarei uma introdução sobre como é o mundo dessa tecnologia, como surgiu Node.js e para o que ela foi desenvolvida, para finalizar mostrarei também as principais características que mais destacam essa tecnologia apresentando suas vantagens e desvantagens.

Nascido em 2009, pelo criador Ryan Dahl junto com 14 colaboradores no início dessa jornada.

O problema principal que eles queriam resolver com essa plataforma foi a de facilitar o desenvolvimento de aplicações real-time e de alta escalabilidade com isso surgiu o Node.js.

Principais características do Node.js:

Linguagem Google Chrome Javascript V8

Você irá desenvolver aplicações utilizando Javascript, algo muito interessante, pois essa linguagem permite trabalhar de forma simplificada tudo o que receber do lado cliente, a curva de aprendizado será pequena, pois o Javascript que você conhece não será diferente do que irá usar no server-side da aplicação, de fato você irá aprender mais como utilizar os diversos módulos (APIs ou Frameworks) e principalmente irá conhecer os diversos Design Patterns do Javascript no Node.js.

Orientado à eventos de I/O

Nativamente o Node.js vem acompanhado com diversos módulos que possibilitam trabalhar com recursosI/O no servidor, isso significa que existem bibliotecas para trabalhar com diversos protocolos, por exemplo: HTTP, HTTPS, DNS, WebSockets (que permite conexão real-time) e outros, além de bibliotecas para manipular arquivos, processamento assíncronos, criptografias, manipulação de objetos JSON e muito mais.

Threads Não-Bloqueantes

Essa é uma característica bem específica do Node.js, ela trabalha com o conceito de Threads Não-Bloqueantes, ou seja, não há um gerenciador de threads, algo que plataformas como Java e .NETpossuem. Isso traz como vantagem uma alta escalabilidade para servidores, pois não há um agente bloqueando e enfileirando threads quando é utilizado um determinado recurso do sistema, porém como desvantagem esse conceito não é recomendável para o desenvolvimento de sistemas transacionais, visto que há uma grande chance de uma perda de íntegra dos dados devido a essa falta de controle. Caso não entenda esse conceito de threads do Node.js, explicarei de forma simplificada esse conceito partindo do princípio que Threads = Usuários acessando seu sistema, quanto mais acessos, mais threads serão instanciadas para utilizarem os recursos da sua aplicação. Quando dois ou mais usuários acessam ao mesmo tempo o mesmo recurso, ocorre o que chamamos de concorrência entre threads.

Em sistemas com arquitetura de Threads Bloqueantes quando 10 usuários simultâneos acessam o mesmo recurso, todos eles são enfileirados, fazendo com que cada um deles utilizem esse recurso um de cada vez e o recurso bloqueia o acesso aos demais usuários dando exclusividade apenas o usuário que esta utilizando-o, isso garante integridade nos dados pois há um controle em que todo mundo acessa-o unicamente. Sistemas bancários e principalmente e-commerces são exemplos que utilizam esse conceito, visto que é obrigatório controlar a concorrência de usuários para garantir a integridade dos dados.

Com isso o conceito de Threads Não-Bloqueantes é totalmente o inverso, ou seja, ninguém controla a concorrência de usuários e isso por mais que não garanta a integridade, traz como benefício um ganho maior em performance, visto que o total de threads concorrentes ficam na memória por um tempo menor e não serão enfileirados para utilizarem o mesmo recurso, e simplesmente o primeiro que utilizar o recurso ganha, os demais perdem ou tentam outra vez. Diversos sistemas pode utilizar esse conceito sem prejudicar os usuários, geralmente são sistemas que trabalham mais com consultas na base de dados do que alterações no mesmo. Alguns exemplos: Games Multiplayer, Web Services, Blogs, Redes sociais, Web Analytics, Chats, e muito mais.Abaixo apresento duas imagens fazendo uma analogia aos mecanismos de Threads Bloqueantes e Não-bloqueantes:

Threads Bloqueantes = Trânsito

Um trânsito de carros passando por um túneo faz uma ótima analogia com Threads bloqueantes, porque para se passar no túneo é necessário formar uma fila de carros para cada carro passar neste local.

Threads Não-Bloqueantes = Cardume

A comparação com um cardume de peixes com Threads Não-Bloqueantes é perfeita, visto que todos os peixes estão livres, não há regras, filas e principalmente se você jogar comida para apenas um peixe (analogia ao uso de um recurso do sistema) apenas o peixe sortudo irá comê-lo e os demais esperarão pela próxima tentativa.

Server-side assíncrono

É possível desenvolver uma aplicação totalmente assíncrona no server-side com Node.js, isso ocorre pelo fato de que Javascript possui funções de callbacks: que são funções que executam-se internamente no parâmetro de uma função comum. Esses callbacks são executados de forma assíncrona e esse conceito permite realizar processamentos paralelos o que é uma grande vantagem em desempenho e diversas APIs do Node.js já são preparadas para trabalhar de maneira assíncrona.

Bom com isso espero que você tenha gostado dessa introdução teórica e nas próximas aulas irei mostrar um pouco de código e algumas dicas e recomendações para aprender mais e mais sobre Node.js.

Crédito: http://udgwebdev.com/nodejs-para-leigos-introducao/

Total line count for your Xcode project

Total line count for your Xcode project

The Apple developer ecosystem definitely takes some getting used to when you come from the Microsoft world. Visual Studio is millions of light years ahead of Xcode. That being said, most things are possible with a little work (and bash skills).

I don't claim to have any experience with *nix command line flavors. My command line experience is limited to several versions of MS-DOS back in the day. Luckily, that's where Google comes in handy.

After trying lots of different things, I landed on the following bash command. Open Terminal on your Mac and navigate to your project's root directory. (Handy trick: type cd with a space after it, then drag the root folder into Terminal, and it'll automatically paste in the entire path).

find . -name "*.[hm]" -print0 | xargs -0 wc -l

You'll get a list of every .h and .m file in your project (searching subdirectories recursively), with how many lines are in each file. Finally, you'll get a total line count for all files.

Note that this counts all lines, even blank lines and comments.

Vitor Yudi Hansen

NIB or COde

I recently saw this post and decided to share here.
because I had the same problems and the same solution.

For iOS development, I don’t use Interface Builder. I haven’t willfully used a NIB (when I say NIB, I mean Interface Builder file, not the specific format) since iOS 2.0. In the past, I’ve worked with a few folks that really liked using Interface Builder. This is an argument I’ve had over and over.

Instead of mindlessly arguing on one side or the other of this, here’s my “go-to” points when I’m trying to win someone over.

Choosing Explicit over Implicit

Choosing to be explicit is my number one reason to do things in code instead. If someone new to the team opens up a view or view controller, they can see right away where everything is and not have to wonder if this file has a NIB.

I have spent countless hours searching for the source of a bug only to discover it’s some checkbox in one of the half dozen inspectors in Interface Builder. If it was in code, it’s simple to glance at the view code and see the source of the problem much quicker.

Tight Coupling

It is much harder to use Interface Builder for reusable views. I constantly create little views and reuse them all over the place. That’s kind of the point of working in an object-oriented environment. If you use Interface Builder and have outlets and forget to connect the outlet in the second place you use it, you crash at runtime.This is terrible. This introduces a whole new class of bugs.

Now we have this thing that crashes simply because we’re using Interface Builder instead of using code. If it was the exact same thing in code, it wouldn’t crash. Even worse, the compiler can check this for you.

Not to mention, if you use lots of custom views, your NIBs will just be a bunch of invisible boxes. So now you have this tight coupling that is even harder to work with if you were to just lay it out in code.

Have you ever sat staring at some code wondering why it’s not working, only to realize you didn’t connect the outlet or action? I hate that.

Working With Others

Have you ever had a merge conflict in a NIB. It’s the worst. (Granted the XIB format has helped, but it’s just awful instead of impossible now.) If you’re working in a large application with several developers, you will waste an enormous amount of time dealing with this issue.

The worst part is if it gets automatically merged wrong, you might not notice until runtime. With code, you can read the diff and understand what’s happening. NIBs (in either format) are not human readable. This also makes looking at the history of a file useless. If it was code, it’s just Objective-C. We’re good at that.

It’s Part of Xcode

This used to be more of an issue, but I think it’s still worth mentioning. To put it lightly, Xcode is not the most stable piece of software in the world. The text editing part works pretty well. Every time I get a crash while editing a NIB, I grumble to myself and wish it was code even more.

The less I have to use Xcode for more than anything except a text editor with completion and a compiler, the happier I am.

Location, Location, Location

Layout code is not hard. Auto-layout is a bit more code than traditional layout, but it’s still not bad. Trying to work with auto-layout in Interface Builder is maddening. Setting outlets to control built-in constraints is just silliness.

It’s so simple to just override layoutSubviews and do your thing. Personally, I find this much easier to work with than auto-layout for most things.

I think this is a lot of people’s biggest fear is working with layouts in code. Once you get the hang of it, it’s so simple. Making your app universal becomes much more trivial than making separate NIBs for iPhone and iPad. You can simply reuse your code instead of create this tight coupling.

Bottom Line

Interface Builder itself is not bad. It does encourage bad practices, prevents reusability (making working with others more difficult), and slows your workflow. Personally, I avoid using Interface Builder (including storyboards) as much as possible. All of the projects I’ve worked on since 2009 haven’t had NIBs unless it was out of my control.

I think you should save yourself some time, learn a few things, and start moving to code. We are programmers after all.

http://blog.teamtreehouse.com/why-i-dont-use-interface-builder


Vitor Yudi Hansen

iOS: Vertical aligning text in a UITextView

The default and expected behavior of a UITextView (multi-line text) out of the box in iOS is to align the text top left in it’s container. That works well most of the time. However I recently had need to either center the text vertically within the control or have all the text align to the bottom of the control.

You can add an observer to the control and when it’s content size changes (text is set), fire a method. The method can then handle how the text is actually positioned in the control. If it doesn’t make sense to do the alignment, it will default to the normal behavior of the control (top vertical alignment).

Here we go:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

- (void) viewDidLoad {    [textField addObserver:self forKeyPath:@"contentSize" options:(NSKeyValueObservingOptionNew) context:NULL];    [super viewDidLoad]; }   -(void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context {    UITextView *tv = object;    //Center vertical alignment    //CGFloat topCorrect = ([tv bounds].size.height - [tv contentSize].height * [tv zoomScale])/2.0;    //topCorrect = ( topCorrect < 0.0 ? 0.0 : topCorrect );    //tv.contentOffset = (CGPoint){.x = 0, .y = -topCorrect};      //Bottom vertical alignment    CGFloat topCorrect = ([tv bounds].size.height - [tv contentSize].height);     topCorrect = (topCorrect <0.0 ? 0.0 : topCorrect);     tv.contentOffset = (CGPoint){.x = 0, .y = -topCorrect}; }

You can decide which you’d like to use, or flush the method out to take an argument for which type of vertical alignment you’d like to use. This works quite well and it would have been nice if the properties were built into the control to begin with.

If you can use it, enjoy.

Vitor Yudi Hansen