Comparativo CLT x PJ

Hoje em dia no mercado de TI (nem só TI, mas TI principalmente), existem várias maneiras de contratação, das quais as mais utilizadas são:

* CLT: Registrado com carteira de trabalho assinada, férias, etc
* PJ: Pessoa Jurídica, na qual o profissional tem que abrir uma empresa e vira um prestador de serviço.

Existem variações da CLT, como a tal de CLT Flex, na qual o funcionário é registrado por um valor menor e recebe o resto legalmente “por fora”. Outra variação é o registro CLT por um valor baixo e recebimento de participação nos lucros na empresa bimestralmente. No meu ponto de vista, estas variações são piadas de mal gosto e nem comento aqui, mas infelizmente essas são as saídas de muitos profissionais que estão ingressando no mercado de trabalho e tem que se “submeter” a tal modalidade.

Em síntese, um profissional registrado como CLT tem todos os direitos previstos na legislação brasileira, tais como: 13, férias, FGTS, etc. Porém ele paga uma alta carga tributária e o valor líquido que ele recebe é menor que o valor bruto, ou seja, o valor registrado em carteira. Um profissional registrado por 4500 reais, recebe aproximadamente 3600 ao final do mês, um desconto de quase mil reais!
Um profissional que presta serviço através de sua empresa (PJ), tem por características pagar menos impostos e ter menos benefícios, portanto, o valor líquido que ele pega em mãos, é muito maior, além disso, as empresas que contratam um profissional PJ, tem um custo muito menos para manter o “funcionário”, portanto, podem pagar mais pelo seu trabalho.

Colocando isso em números para podermos comparar as duas modalidades de contratação, vamos a um exemplo abaixo:

Profissional CLT registrado por 4500 reais.

Profissional PJ com o valor hora de 50 reais calculando um mês de 168 horas. (50 * 168 = 8400) – Este valor hora é de um programador Java Sênior, mas podem haver variações.

Para calcularmos o real salário do funcionário CLT, não basta somente verificar o valor que ele recebe líquido, temos que colocar todos os benefícios na equação, alguns exemplos são:

3600 – Valor líquido ao fim do mês
400 – INSS (este valor retorna algum dia na aposentadoria)
300 – 13 (valor do 13 dividido por 12)
300 – 14 (algumas empresas tem 14/Participação nos lucros, é a mesma conta que para o 13)
1000 – Plano de saúde executivo familiar (profissional + esposa + filhos – eu cotei o melhor plano da Amil)
250 – Ticket refeição
250 – Vale transporte

Os benefícios variam de empresa para empresa, então esta conta é bem pessoal, citado acima alguns exemplos comuns, baseado nestes exemplos, podemos dizer que o salario do profissional CLT é então:

3600 + 2500 = 6100

Agora, calculando o valor do profissional PJ, temos 50 * 168 = 8400.

Os valores do CLT e do PJ podem variar com adição de horas extras, mas NUNCA se deve levar em consideração este fator, visto que é algo que pode não existir.

Em cima do valor de 8400, o profissional PJ vai pagar aproximadamente 15% de impostos/escritório/etc, é um valor alto, mas a média é entre 10 a 15% mesmo, para fazermos estas contas, sempre devemos chutar alto.

Descontados os 15%, o PJ tem ao final do mês 7140 reais na mão. Agora veja que o PJ não tem NENHUM dos benefícios do CLT, então este valor dos benefícios deve ser descontado do PJ:
7140 – 2500(benefícios do CLT) = 4640

Agora destes 4640, desconta-se o salário líquido do CLT (3600), que vai dar uma diferença de 1040.

Concluindo:

Existem ‘N’ fatores que podem entrar nesta equação, o CLT pode ter mais ou menos benefícios, o PJ pode ter algum benefício também, porém em geral, O CLT tem que considerar que tem férias, licenças (maternidade, doença, seguro desemprego, etc)FGTS, etc.. enquanto o PJ não tem NADA disso, se ele quiser o benefício, vai ter que pagar de seu próprio bolso.

Outro fator que muitas pessoas consideram é a estabilidade do CLT. Para uma empresa mandar um profissional PJ “embora”, é muito mais prático e não tem custo algum, no máximo tem um contrato assinado que normalmente dá até este direito para a empresa, ai o PJ vai embora sem receber nada! Para mandar um CLT para a rua, é caro! Uma empresa sempre vai preferir mandar o PJ para a rua! Eu não levaria em consideração este fator na área de TI se você for um bom profissional (bom CV, falar inglês, etc), pois o mercado é aquecido e não faltam vagas.

O PJ normalmente não tem plano de carreira, o CLT costuma ter. Algumas empresas também pagam cursos para os profissionais CLT, e isso tem seu valor e tem que entrar na conta.

Por outro lado, o PJ pode trabalhar muito, fazer horas extras irreais, e recebera por isso, um CLT, esta limitado legalmente em seu numero de horas (40 horas mês).

Para abrir uma empresa para prestar serviço como PJ, você vai ter um custo, e para fechar a empresa vai ter um custo maior ainda, o CLT não tem custo algum (só o da foto 3×4 :-)).

Se um PJ falta do trabalho, o problema é dele, até com atestado médico, e não vai receber por isso, então ele não pode nem pensar em ficar doente! Se o CLT falta, com atestado, ele recebe normalmente, se fica doente, tem amparo legal!

Legalmente, uma empresa (PJ) deve gastar o lucro da empresa com A empresa, o que a maioria das pessoas faz é simplesmente pegar esse dinheiro e torrar com gastos pessoais, casas, carros, etc. Se a empresa cai em um pente fino da Receita Federal, irá pagar uma multa sobre tudo que não for comprovado como gasto da empresa PJ, ou seja, sobre TODA sua retirada! Tenho amigos que cairam nessa e demoraram mais que 5 anos para se “levantar” financeiramente.

Agora, se perguntarem qual minha preferencia, eu digo categoricamente: CLT.

O valor PJ tem que ser muito alto para justificar uma migração para o mesmo. Tem que dar dinheiro para pagar todos os benefícios do CLT e sobrar. As vezes as pessoas só olham o valor direto que o PJ rende e não olham os outros valores que o CLT propicia e caem em ilusões!

Ao analisar uma proposta, coloque TODOS os fatores na ponta do lápis e não tome uma decisão precipitada.

Texto do Juliano Marcos Martins para o site APInfo

Facebook Comments

Entendendo o modelo Multi-tenancy para clientes

No futuro, O modelo SaaS vai requerer tecnologias e arquiteturas especificamente desenhadas para operar em nuvem. Entretanto, essas novas arquiteturas e tecnologias vão aparecer a longo prazo, com modelos intermediários e transitórios surgindo no curto e médio prazo, fazendo a ponte entre os modelos computacionais existentes hoje e os futuros modelos em nuvem.

Atualmente, a maioria dos softwares existentes foi desenhada para operar nos data centers das empresas, sujeitos a contratos específicos de licença de uso. As próprias plataformas de aplicação como Java e .Net foram desenhadas para operarem no modelo on-premise.

Em um modelo SaaS em nuvem, as aplicações podem ser oferecidas como serviços a muitas organizações. Para os provedores desses serviços, é imprescindível que os recursos computacionais a serem oferecidos sejam o mais amplamente compartilhados.

Para os usuários, é fundamental que uma falha de um software na operação para um outro usuário não o afete. Além disso, cada usuário gostaria de adaptar, na medida do possível, a aplicação às suas características específicas.

Porém as arquiteturas de software atuais não atendem a esse novo cenário. É necessário um novo modelo arquitetônico de software, chamado de multitenancy ou multi-inquilino.

A proposta do modelo SaaS é ter uma aplicação atendendo aos múltiplos clientes, chamados de tenants ou inquilinos. Inquilinos não são usuários individuais, mas empresas clientes do software.

Uma arquitetura multi-inquilinos (em alguns casos, a literatura fala em multi-arrendatário, mas eu prefiro usar o termo multi-inquilino) é uma arquitetura essencial para um ambiente em nuvem, pois permite que múltiplos inquilinos (empresas/clientes) compartilhem os mesmos recursos físicos como um aplicativo ERP, mas permaneçam logicamente isolados.

Os modelos multi-inquilino são:

01 – Inquilino isolado: Neste modelo, cada inquilino tem seu próprio stack de tecnologia, não havendo compartilhamento de recursos. Na prática, embora o usuário sinta a experiência de multi-inquilino, pois a aplicação é oferecida a múltiplos clientes a partir do mesmo data center, este modelo não é multi-inquilino. É similar ao modelo tradicional de hosting (hospedagem), no qual cada usuário tem seu próprio conjunto de recursos computacionais e sua própria instância da aplicação. Para a uma oferta SaaS, este modelo carece de agilidade e de elasticidade, porque adicionar um novo inquilino requer o provisionamento de sua própria instância de hardware e de software. Também não permite economia de escala. Os provedores que comercializam softwares no modelo tradicional podem oferecer esta opção, sem alterar sua aplicação. Embora não seja verdadeiramente Computação em Nuvem, é um passo nessa direção, oferecendo como atrativo a facilidade de uma rápida oferta para SaaS.

02 – Multi-inquilino via hardware compartilhado (virtualização): Neste modelo, cada inquilino tem seu próprio stack de tecnologia, mas o hardware é alocado dinamicamente a partir de um pool de recursos, via mecanismos de virtualização. Bastante similar ao modelo anterior, mas permitindo elasticidade na camada do hardware. Elasticidade é fundamental ao modelo de Computação em Nuvem, que demanda mecanismos de alocação e liberação de recursos de forma dinâmica. Este modelo permite uma entrada rápida na Computação em Nuvem, principalmente por provedores de aplicações e de infraestrutura, porque não demanda redesenho da aplicação. Entretanto, apresenta limitações, pois a unidade de alocação e liberação de recursos é a maquina virtual onde aplicação vai operar.

03 – Multi-inquilino via container: Neste modelo, vários inquilinos são executados na mesma instância de um container de aplicação (um servidor de aplicações), mas cada inquilino está associado a uma instância separada do software de banco de dados. O ambiente de execução é compartilhado entre vários inquilinos, mas a plataforma de dados é a mesma. A premissa do modelo é que o isolamento do banco de dados garante integridade dos dados dos inquilinos, ao mesmo tempo em que o container de execução, por ser compartilhado, oferece as vantagens de elasticidade e de customização. Para garantir o isolamento dos inquilinos dentro de uma única instância do container ou servidor de aplicações, este deve ser desenhado com funcionalidade para gerenciar a alocação de recursos aos seus inquilinos.

04 – Multi-inquilino via todo o stack de software compartilhado: É uma evolução do modelo anterior, agora com todo o stack de software sendo compartilhado. Neste modelo, além do container da aplicação, também uma única instância do banco de dados é compartilhada por todos os inquilinos.

O modelo (02), multi-inquilino por compartilhamento de hardware, permite uma transição para SaaS com baixo custo e baixo impacto. A razão é simples: preservam os modelos de programação e tecnologia já conhecidos.

Os modelos (03) e (04) implementam um nível bem mais avançado de SaaS e provavelmente serão os modelos dominantes no longo prazo. Mas, atualmente, é implementado apenas por empresas de software que não possuem legado para sustentar e, portanto, podem romper com os modelos tradicionais, como por exemplo, a Salesforce.

Como são nativos ao modelo em nuvem, oferecem níveis elevados de flexibilidade e de elasticidade, mas ao custo de disrupção nos modelos atuais de programação.

Nos próximos anos, veremos um intenso debate sobre os prós e contras dos vários modelos de multi-inquilinos, mas no longo prazo os modelos (03) e (04) vão prevalecer.

Empresas de software que precisam suportar sua imensa base de clientes com sistemas legados estão optando por uma evolução gradual, adotando inicialmente o modelo (02), mas incentivando uma evolução posterior para os modelos (03) e (04), à medida que o mercado e as tecnologias disponíveis forem amadurecendo o suficiente para suportarem clientes corporativos de grande porte.

Texto de Cezar Taurion para o iMasters

Facebook Comments

Definição de Full-Stack Developer

Full stack web developer é um perfil de desenvolvedor que consegue trabalhar não somente com programação, pois compreende de forma razoável uma porção de outras tecnologias envolvidas em um sistema: banco de dados, infra-estrutura, sistema operacional, servidor web, CSS/HTML (conforme ilustração do @bvafaretto).

Estes profissionais conseguem solucionar uma grande gama de problemas deste “stack” todo e, quando precisam de ajuda, precisam de pouca instrução de um profissional especialista na referida tecnologia para conseguirem prosseguir. O conjunto todo é chamado de “stack”, pois se trata de uma “pilha” de tecnologias (pense nas tecnologias do servidor embaixo, e as do cliente em cima). Então “full-stack” é aquele desenvolvedor que lida com todas as camadas da pilha, e não só com uma parte delas.

Full Stack Web Developer

Ao contrário do que é pensado, não é preciso ser uma desenvolvedor experiente para considerar-se “full stack”. Isto pode ocorrer perfeitamente nos primeiros anos do profissional, basta o mesmo ter contato com estas diferentes tecnologias, o que normalmente ocorre em empresas menores (onde nem sempre há um profissional disponível para cada tecnologia) ou empresas que estimulam este tipo de situação (arrisco dizer que seja a maioria das que trabalham com alguma metodologia ágil).

 

Facebook Comments

Analista Desenvolvedor .NET Sênior – Barueri

Oportunidade para atuar na região de Barueri em empresa de tecnologia com foco em desenvolvimento, manutenções, melhorias e novos módulos.

Importante Inglês Avançado

Interessados encaminhar curriculo com pretensão salarial para o e-mail [email protected]

Facebook Comments

Github: o novo curriculum do programador

Cada vez mais, conversando com amigos de empresas que buscam contratar programadores, uma coisa é consenso: em todas as entrevistas a pergunta “Você tem GitHub?” é cada vez mais frequente e unânime.

Mas por que tudo isso? Porque hoje, muitas empresas buscam avaliar o programador pelas suas realizações.

E isso é ótimo! Sabe por que? Porque o GitHub permite que você, mesmo sem experiência de mercado, possa mostrar a qualidade do código que produz. Sabe aquela velha queixa dos recém-formados que buscam uma colocação no mercado e as empresas pedem programadores com experiência prévia? Então isso pode estar com os dias contados.

Para quem não conhece, o GitHub é um repositório de códigos que funciona como um servidor de versões e que ainda é uma rede social de programadores. Sim, uma rede social na qual suas postagens são: programas! E você pode seguir projetos, clonar projetos para seu repositório local (seu HD) e fazer suas próprias modificações. E com isso, seu futuro avaliador em uma entrevista de emprego irá avaliá-lo, não pelo curriculum que você entregou, mas pelo seu histórico como programador.

Para você que ainda não criou sua conta no GitHub e está procurando um emprego, crie-a hoje! Não espere. E coloque todos os seus códigos lá, todos os seus projetos, mesmo os acadêmicos!

Mas e se aí você me perguntar: “pôxa Isidro, mas meus códigos estão muito ruins, devo colocá-los mesmo assim?”. Aí vou te responder: depende do quanto você quer convencer seu entrevistador. Se seu código não está lá aquelas maravilhas na sua visão, que tal “dar um tapa” nele, estudar melhor boas práticas, correr um pouco atrás de se atualizar em relação aos padrões de projetos, organizar seus pacotes, melhorar a legibilidade de seu código? Pronto para se mexer?

O que quero provocar em vocês, meus caros alunos é a necessidade de estarem antenados ao que o mercado tem notado e dado importância.

Conhecer uma ferramenta de controle de versões é fundamental para se trabalhar em equipe. O GitHub permite isso, além de uma série de outras integrações com outras ferramentas. E ainda mais é que você pode (e deve) mostrar todo seu potencial para a galera.

Se quiser saber mais, dá uma olhada nesses links aqui

http://www.github.com

https://help.github.com/ que vai te dar o step-by-step pra começar a trabalhar com ele.

Pense nisso! E #vamosprogramar!

Artigo do Professor Isidro para a Abraweb

Facebook Comments

Usando o Fetch API ao invés do jQuery.Ajax

Segundo o site buildwith o jQuery ainda é utilizado por cerca de 78.2% dos principais sites na internet. Sim. 78% dos sites ainda usam de alguma forma o icônico $.

Atualmente com seus aproximadamente 86K na versão 2.2.2, o jQuery possui uma série de recursos importantes para nosso dia-a-dia como desenvolvedores front-end. Com o passar do tempo os browsers foram se atualizando, e a cada dia vemos a não necessidade de adicionar o jQuery em nossos projetos.

Por incrível que possa parecer, muita gente ainda adiciona o jQuery inteiro no projeto simplesmente por causa do jQuery.ajax. Nesse post vamos conhecer a Fetch API, talvez este seja o motivo que você estava procurando para abandonar de vez o jQuery.

Segundo o site caniuse a Fetch API está presente em aproximadamente 55% dos navegadores do mundo. Isso significa que para utilizarmos em nossos projetos vamos precisar de um Polyfill. É só seguir as instruções de instalação descritas no repositório ou utilizar diretamente do cdnjs.

A Fetch API utiliza Promises. Se você nunca utilizou Promises no seu desenvolvimento, dê uma lida nesse ótimo artigo do Jake Archibald antes de continuar.

Utilização Básica

Se você estiver em uma versão de browser compatível ou estiver utilizando o polyfill o objeto window agora possui um método chamado fetch.

fetch('/some/url', { method: 'get' })  
   .then(function (response) { })
   .catch(function (err) { // Error });

A assinatura do método é fetch(request[, options]) onde request pode ser uma String ou uma instância da classe Request e options sendo um parâmetro opcional que quando declarado deve ser um Object contendo os seguintes parâmetros:

  • method
    • O método do request. GET, POST, etc.
  • headers
    • Headers que você deseja enviar no request.
  • body
  • mode
    • Modo do request. cors, no-cors ou same-origin.
  • credentials
    • Se o request deve incluir os cookies para o domínio atual. omit, same-origin ou include.
  • cache
    • O modo de cache. default, no-store, no-cache, force-cache ou only-if.
  • redirect
    • O modo de redirect. follow, error ou manual.
  • referrer
    • no-referer, client ou uma URL.

Todas as chamadas para o método fetch retornam uma Promise que são resolvidas com uma Response.

Utilizando a classe Request

Ao invés de usar uma String é possível passar uma instância da classe Request como o primeiro parâmetro do método fetch.

fetch(new Request('/users.json', {  
  method: 'POST', 
  mode: 'cors', 
  redirect: 'follow',
  headers: new Headers({
    'Content-Type': 'text/plain'
  })
})).then(function(response) { });

Com isso não é necessário passar o parâmetro options já que todas as opções presentes no objeto options são atributos da instância da classe Request.

Uma vez criada a instância de Request, todos seus parâmetros são read-only, ou seja, não podem ser modificados fora da construção da instância.

Um ponto importante sobre a instância da classe Request é que após ser criada ela só pode ser utilizada uma única vez pelo método fetch. Caso você queira refazer um determinado request utilizando as configurações de uma instância previamente criada basta utilizar o método clone presente na classe Request para efetuar uma nova chamada fetch.

Veja um exemplo abaixo:

var req = new Request('/users.json', {  
  method: 'POST', 
  mode: 'cors', 
  redirect: 'follow',
  headers: new Headers({
    'Content-Type': 'text/plain'
  })
});

var handleFailure = function () {  
  if (shouldRetry()) {
    fetch(req.clone()).then(handleSuccess);
  }
};

fetch(req).then(handleSuccess).catch(handleFailure)  

O objeto Response.

Toda Promise retornada pelo método fetch é resolvida com uma instância de Response – Abaixo vemos um exemplo onde fazemos um request para um arquivo JSON e transformamos o objeto Response em um JSON.

fetch('file.json')  
  .then(function (response) { 
    // Converte a resposta para um JSON
    return response.json();
  })
  .then(function(json) {
    console.log(json); 
  });

Além do método .json() uma instância de Response pode ser convertida para .text(), .blob(), .arrayBuffer() ou .formData(). A instância também possui atributos:

  • type
  • url
  • status
  • ok
  • statusText
  • headers

Como fazer um POST

É comum enviar dados para o backend utilizando POST ou PUT — Abaixo está um exemplo de como enviar dados para backend utilizando a Fetch API.

fetch('/post', {  
  method: 'post',
  body: JSON.stringify({
    email: [email protected]',    
    password: '******'
  })
});

Upload de arquivos?

var input = document.querySelector('input[type="file"]')

var data = new FormData()  
data.append('file', input.files[0])

fetch('/upload', {  
  method: 'post',
  body: data
});

Not always a bed of roses. Sim, existem problemas funcionalidades não implementadas.

Como a Fetch API é relativamente nova, existem recursos presentes no XMLHttpRequest que ainda não foram incorporados na Fetch API. Muitos dos problemas já estão endereçados no repositório GitHub do projeto.

Não é possível cancelar um request.

Utilizando o jQuery.ajax é algo bem trivial.

var xhr = $.ajax({  
  type: "POST",
  url: "some.php",
  data: "name=John&location=Boston",
  success: function(msg){
    alert("Data Saved: " + msg);
  }
});

xhr.abort();  

Já existe uma discussão aberta no GitHub sobre qual deveria ser a melhor forma de fazer algo parecido com a Fetch API.

Não é possível acompanhar o progresso da requisição.

$.ajax({
  xhr: function() {
    var xhr = new window.XMLHttpRequest();
    xhr.upload.addEventListener("progress", ... );
  }
});

Existe a intenção de incluir a Stream API para que isso seja possível.

Finalizando

Talvez você não esteja disposto a abrir mão do jQuery no momento. Tudo bem. Não tem problema. Porém é interessante ver como os browsers estão se atualizando trazendo APIs simples que fornecem exatamente as mesmas algumas funcionalidades que o jQuery tem há algum tempo. Até mais.

Artigo do engenheiro de software do site VivaReal William Lepinski

Facebook Comments

Analista .NET Pleno – São Bernardo do Campo

Experiência Plena em Análise e desenvolvimento em .NET, CSharp, HTML, VB.Net e banco de dados Oracle e SQL.

Diferencial: Já ter atuado em assistências de seguradoras ou seguradoras

Local: São Bernardo do Campo SP
Encaminhar currículo com pretensão para o e-mail:[email protected]

Facebook Comments