Jump to content

Fabiano Passianoto

Administradores
  • Contagem de Conteúdo

    34
  • Ingressou

  • Última visita

  • Dias Ganhos

    4

Tudo que foi postado por Fabiano Passianoto

  1. Olá Pacifico Vamos ver se eu entendi sua necessidade Para selecionar a quantidade de funcionários por setor e o total de vinculos, poderiam ser SQLs diferentes ou até no mesmo. Mas uma coisa não ficou muito claro, qual é a estrutura da sua tabela, se a cada registro, é o registro de uma pessoa na tabela, juntamente qual o seu tipo de vinculo, e o seu setor, então presumo que essa tabela seria como um registro de funcionário. Então cada linha é um funcionário, agrupar isso por setor responde a primeira questão. Select Setor, count(*) as qtde from tabela group by 1 Agora vc quer saber quantas pessoas de cada vinculo vc tem por setor, então vamos agrupar isso por setor e vinculo. Select Setor, vinculo, count(*) as qtde from tabela group by 1,2 Agora eu quero que tudo isso retorne no mesmo select, transformamos as duas querys em subselects, e linkados elas pelo setor, que é o ponto em comum. select tbSetor.setor, tbSetor.qtde_pessoas_setor, tbVinculo.qtde_vinculos_setor from ( Select Setor, count(*) as qtde_pessoas_setor from tabela group by 1 ) tbSetor join ( Select Setor, vinculo, count(*) as qtde_vinculos_setor from tabela group by 1,2 ) tbVinculo on TbVinculo.setor = tbSetor.setor Responde aí, se eu atingi seu objetivo, ou se a estrutura que eu presumi da sua tabela, seja diferente.
  2. Um épico é utilizado no gerenciamento de projetos Scrum ou Kanban para descrever um objetivo geral de alto nível que é muito grande ou complexo para ser concluído em uma única iteração. É uma forma de organizar e priorizar as iniciativas e requisitos do projeto em um nível superior, para que a equipe possa trabalhar de forma mais eficiente e eficaz. O épico pode ser usado para representar uma história de usuário ou um conjunto de histórias de usuário relacionadas. Ele é usado para definir e comunicar o escopo do projeto, para que a equipe possa entender as expectativas e trabalhar em direção a um objetivo comum. Os épicos também são usados para dividir um projeto em partes menores e mais gerenciáveis, para que a equipe possa realizar entregas de valor em cada sprint. Alguns exemplos de épicos podem incluir o desenvolvimento de um novo produto, a melhoria de um recurso existente, a atualização de um sistema legado, a otimização de um processo de negócios, reformulação de uma arquitetura em um portfólio tudo aquilo que se possa organizar macroamente, entre outros. Independente da metologia o épico no sistema de gerenciamento de projetos, tem a mesma finalidade que é gerenciar um objetivo macro para ser concluído e uma única vez. Sendo um épico ele pode descrever uma funcionalidade geral ou um conjunto de funcionalidades que agregam valor ao negócio. geralmente é dividido em histórias de usuário menores e mais gerenciáveis, que podem ser concluídas dentro de pequenos ciclos de desenvolvimento. O objetivo do épico é fornecer uma visão estratégica do que precisa ser feito ele ajuda a manter o foco na entrega de valor para o cliente e ajuda a equipe a priorizar as histórias de usuário que são mais importantes para o negócio. Um épico pode ser considerado como parte de um roadmap, mas não é a mesma coisa. Um roadmap é uma visão de mais alto nível que descreve a direção geral do produto ou de um projeto e as principais entregas ou marcos que devem ser alcançados para atingir os objetivos de negócio. Ele geralmente cobre um período mais longo, como 6 a 12 meses, e é atualizado periodicamente à medida que novas informações se tornam disponíveis. Enquanto um roadmap fornece uma visão geral da direção do produto ou do projeto, um épico é mais específico e detalhado. Ele ajuda a equipe a entender as expectativas e trabalhar em direção a um objetivo comum, mas ainda é uma unidade de trabalho mais granular do que um roadmap, poderiamos dizer que um roadmap seria a soma de vários épicos. Em resumo, um épico pode ser considerado uma parte do roadmap, pois ajuda a definir os objetivos de negócio que o roadmap busca alcançar, O épico é uma unidade de trabalho específica, enquanto o roadmap é uma visão de alto nível da direção geral do produto ou do projeto. Referências bibliográficas: Schwaber, K., & Sutherland, J. (2017). Guia Scrum: O Guia Definitivo para o Scrum: As Regras do Jogo. Scrum.org. Kniberg, H. (2015). Kanban e Scrum - Obtendo o Melhor de Ambos. Editora Casa do Código. Larman, C., & Vodde, B. (2010). Escalando Ágil: Práticas globais para múltiplos times entregarem um único produto. Bookman Editora. Scrum Guide: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf "Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty" de C. Lombardo e B. McCarthy (2017)
  3. Introdução O Manifesto Ágil é um guia para o desenvolvimento de software em equipes, que valoriza a colaboração, a comunicação e a adaptação às mudanças de requisitos. Ele foi criado como uma alternativa aos processos mais rígidos e burocráticos de desenvolvimento de software, que muitas vezes resultavam em projetos atrasados e com baixa qualidade. A adoção dos valores e princípios descritos no Manifesto Ágil pode ajudar equipes a entregarem software de qualidade dentro do prazo e com satisfação do cliente. Ele é um dos princípios fundamentais para o desenvolvimento de software. Um documento que descreve um conjunto de princípios e valores que orientam a metodologia ágil de desenvolvimento de software. Foi criado em 2001 por um grupo de 17 desenvolvedores que se reuniram em Utah, nos Estados Unidos, para discutir formas mais eficientes de desenvolver software. Eles utilizavam diversas ferramentas da área de tecnologia, porém com objetivos e propósitos de trabalho similares: Como XP (Extreme Programming, DSDM (Adaptive Software Development), Crystal, FDD (Feature-Driven Development), Pragmatic Programming Na década de 1990, a indústria do desenvolvimento de software sofria com diversos problemas, como a perda de enormes montantes de dinheiro em projetos que, com altíssima frequência, eram entregues com atraso, excediam orçamentos e estavam rodeados de baixa qualidade. Assim, os desenvolvedores e o mercado como um todo foram amplamente afetados, já que os usuários do software não estavam satisfeitos. Dessa forma, as empresas que demandavam se prejudicavam por causa do prazo e custo. Já os próprios desenvolvedores corriam grandes riscos de serem demitidos, pois não adiantava trabalharem cada vez mais intensamente, porque os problemas continuavam persistindo. O grupo que compôs o agile manifesto chegou a conclusão de que as empresas estavam se preocupando muito mais com o planejamento e a documentação dos ciclos e, por fim, se esquecendo do ponto-chave: agradar os clientes. As empresas até ditavam valores a respeito de “excelência” e “integridade”, porém ofereciam poucos guias para as pessoas e, em especial, para os desenvolvedores de software. Anteriormente à reunião, em 2000, houve um encontro de líderes da comunidade do Extreme Programming (XP). Dentre os principais diálogos, debateram sobre a relação entre o XP e os Método Leves – Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, entre outros. Com isso, notaram que o XP era melhor como um método específico, porém com espaço comum entre ele e os métodos leves. Manifesto para Desenvolvimento Ágil de Software Robert Cecil Martin, idealizou então um encontro para pessoas interessadas nos Métodos Ágeis. Uma grande lista de desenvolvedores foi contatada, no entanto, apenas dezessete pessoas – incluindo ele – compareceram a um momento que iria impactar o mundo dos negócios de uma maneira que elas até então não pudessem prever. Durante a reunião, eles abordaram temas como a burocratização do processo de desenvolvimento de software e a verticalidade do sistema. A partir de muitas reflexões e estudos, observaram os pontos comuns de projetos que tiveram sucesso em suas metodologias e chegaram a um consenso sobre como deveriam ser os métodos de desenvolvimento de software. Dessa forma, foi criado o Manifesto para Desenvolvimento Ágil de Software, ou simplesmente Manifesto Ágil (Agile Manifesto). Não se trata, como poderia parecer à primeira vista, de um desprezo aos elementos e ferramentas tradicionais do desenvolvimento de software, mas sim do estabelecimento de uma escala de valores, na qual a flexibilidade e a colaboração são mais relevantes do que a rigidez de processos e planejamento clássicos. Agile Manifesto: era moderna de inovação O Manifesto, então, aborda valores que todos os profissionais ali reunidos concordaram em seguir e disseminar. E, posteriormente, definiu uma cultura, tornando-se uma espécie de “grito de guerra” para a indústria de software e para aqueles 17 desenvolvedores. A era ágil moderna surgiu por necessidade, em uma indústria que precisava urgentemente de mudanças. Com o passar do tempo, os princípios e as práticas do agile manifesto foram vistos como valiosos nos mais diferentes contextos, permitindo que muitos projetos de TI evitassem os históricos de atrasos e estouros de orçamento. De forma que, consequentemente, as empresas entregassem mais valor, a partir de menos trabalho. Abaixo, a lista de nomes que integraram a “Aliança Ágil” – termo que eles usaram para dirigir a si mesmos enquanto assinantes do manifesto: Robert C. Martin, o “Uncle Bob” Ken Schwaber, co-criador do Scrum. Jeff Sutherland, o inventor do Scrum. Kent Back, co-criador da eXtreme Programming (XP). Ron Jeffries, co-criador da eXtreme Programming (XP). Mike Beedle, co-autor de Desenvolvimento Ágil de Software com Scrum. Arie van Bennekum, da Integrated Agile. Alistair Cockburn, criador da Metodologia Ágil Crystal. Ward Cunningham, criador do conceito wiki. Martin Fowler, desenvolvedor parceiro da Thoughtworks. James Grenning, autor de Test Driven Development. Jim Highsmith, criador do Adaptive Software Development (ASD). Andrew Hunt, co-autor de O Programador Pragmático. Jon Kern, atuante até os dias de hoje em assuntos de agilidade. Brian Marick, cientista da computação e autor de vários livros sobre programação. Steve Mellor, cientista da computação e um dos idealizadores da Análise de Sistema Orientado a Objetos (OOSA). Dave Thomas, programador e co-autor de The Pragmatic Programmer. 4 valores do Manifesto Ágil Confira, a seguir, os valores que foram retirados na íntegra do site oficial dos criadores do Manifesto Ágil: 1- “Indivíduos e interações mais que processos e ferramentas” O desenvolvimento de software é uma atividade humana. Desse modo, uma rede de comunicação de qualidade permite uma interação entre todas as partes, podendo ela ser uma ótima aliada. 2- “Software em funcionamento mais que documentação abrangente” Clientes buscam e pagam por resultados. Por isso, o maior indicador de que a equipe realmente construiu algo e de que o trabalho foi bem executado é o software em pleno funcionamento. A documentação também é importante. Contudo, na maioria das vezes, a perda de tempo com tanta documentação e solicitação de aprovação não é transmitida de maneira objetiva e com muita clareza para o cliente. 3- “Colaboração com o cliente mais que negociação de contratos” Todos podem contribuir para que o resultado seja de qualidade. Dessa forma, deve haver a colaboração entre o time de desenvolvimento e o cliente. Eles devem tomar decisões em conjunto e trabalhar em equipe em prol de um único objetivo. Afinal, não é do interesse da empresa ir contra o seu cliente e, claro, é do interesse do cliente ter voz ativa no processo de criação do seu produto ou serviço. 4- “Responder a mudanças mais que seguir um plano” Há sempre um esqueleto (protótipo) de como desenvolver o software, mas cada cliente e cada produto demanda uma necessidade específica. Portanto, é necessário estar sempre atento aos feedbacks obtidos durante o processo de criação e observar o cenário do mercado a fim de se obter respostas mais rápidas para as eventuais mudanças. A rigidez não deve existir dentro da metodologia ágil. O plano, portanto, deve ser adaptado sempre que se fizer necessário. 12 princípios do Manifesto Ágil De acordo com os criadores do Manifesto Ágil, os 12 princípios agile manifesto são: “Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado” “Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente” “Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo” “Pessoas de negócio e desenvolvedores devem trabalhar em conjunto diariamente por todo o projeto” “Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho” “O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é por meio de conversa face a face” “Software funcionando é a medida primária de progresso” “Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente” “Contínua atenção à excelência técnica e bom design aumenta a agilidade” “Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial” “As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis” “Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.” Por fim, o que diz o Manifesto Ágil? Os signatários escreveram no começo, antes dos valores, o seguinte: “Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo”. A filosofia que foi usada para interpretar os valores que têm maior importância são: indivíduos e interações, software em funcionamento, colaboração e resposta a mudanças. Enquanto os outros atuam de forma secundária e complementar, como pano de fundo, sendo, respectivamente: processos e ferramentas, documentação abrangente, negociação de contratos e plano. O objetivo é apontar os rumos de um time ágil visando a potencialização de seus projetos e a escalabilidade dos resultados. Quando se trata do ciclo de vida de projetos ágeis, por exemplo, o começo e o final de cada fase representa um ponto de reavaliação do trabalho que já foi e será realizado. Desse modo, é mais fácil e rápido diagnosticar e corrigir os erros que impactam na performance do trabalho. Em suma, o Manifesto Ágil diz que os membros querem restaurar o equilíbrio e abraçar a modelagem de desenvolvimento. Entretanto, não para arquivar algum diagrama em um repositório corporativo empoeirado e lotado de documentação ou centenas de páginas de volumes nunca mantidos e raramente usados, mas sim, reconhecendo os limites do planejamento em meio a um ambiente turbulento. A importância do Manifesto Ágil: O manifesto, a princípio, foi desenvolvido como uma ferramenta de gestão para o desenvolvimento de softwares ágeis, única e exclusivamente com foco na opinião do cliente, a fim de entregar algo positivo em relação às experiências do usuário. A metodologia ágil tem como objetivo, portanto, entregar bons produtos aos clientes. E, assim, operar em um ambiente que faz mais do que falar sobre “pessoas como nosso ativo mais importante”, mas na verdade agir, de fato, como se as pessoas fossem o mais importante. O Agile Manifesto foi um grande marco na indústria de desenvolvimento de software, uma vez que, graças a ele, a ideia de que a construção de um software seguia apenas uma receita foi transformada. Desde a sua criação, os princípios foram adotados em larga escala e em diferentes níveis de negócios e projetos. Tamanha é a sua eficiência, que acabou gerando novas ramificações para outras áreas da tecnologia e, dessa forma, tornou-se inegável o seu impacto para empresas de diversos setores. Conclusão Pessoal O Manifesto Ágil trouxe uma inovação significativa na forma como as equipes de desenvolvimento de software trabalham. Antes do Manifesto Ágil, a metodologia de desenvolvimento mais comum era a chamada "cascata" (waterfall), que consistia em uma série de etapas sequenciais, como planejamento, análise, design, implementação e testes. Cada etapa era concluída antes de passar para a próxima, e as mudanças de requisitos ou problemas descobertos durante a execução do projeto geralmente resultavam em atrasos e retrabalho. O Manifesto Ágil propõe uma abordagem diferente, que valoriza a comunicação, a colaboração e a entrega de valor ao cliente em ciclos curtos e frequentes. Em vez de seguir um plano rígido, a equipe trabalha em conjunto com o cliente para identificar os requisitos mais importantes e priorizá-los. Em seguida, a equipe desenvolve e testa iterativamente pequenos incrementos de software, entregando valor ao cliente a cada ciclo. As mudanças de requisitos são bem-vindas e fazem parte do processo natural de desenvolvimento, em vez de serem consideradas um obstáculo. Essa abordagem ágil permite que as equipes de desenvolvimento de software sejam mais flexíveis e responsivas às mudanças no mercado e nas necessidades do cliente. Além disso, o foco na entrega de valor em ciclos curtos permite que o cliente obtenha feedback mais rapidamente e possa ajustar seus requisitos de acordo com a evolução do projeto. Essa inovação na forma de desenvolver software tem sido amplamente adotada por empresas em todo o mundo e tem se mostrado eficaz em aumentar a produtividade, a qualidade e a satisfação do cliente. O mais importante, então, é a possibilidade de que um grupo tenha poder de aplicar ou não as ideias do agile manifesto em uma situação específica. Entretanto, sem deixar de lado a sua essência. E, se conseguirem fazer essa aplicação direito, logo, são ilimitadas as possibilidades em um mundo totalmente dinâmico, as pessoas até podem fazer novas interpretações e metodologias, como a atual aplicada na TecnoSpeed conhecida internamente como TecnoKanban.
  4. Leadtime é o tempo decorrido desde o início de uma atividade até a sua conclusão. Em uma empresa de software, o leadtime pode ser considerado bom se a empresa conseguir entregar seus produtos ou serviços aos clientes dentro de prazos razoáveis, com qualidade e sem atrasos. A seguir, algumas sugestões para considerar um bom leadtime em uma empresa de software: Definir processos claros e bem estruturados para as atividades da empresa, desde o planejamento até a entrega final. Isso ajudará a minimizar o tempo de espera em cada etapa do processo. Identificar gargalos ou pontos de estrangulamento no fluxo de trabalho e trabalhar para eliminá-los ou reduzi-los. Isso pode incluir a automatização de processos, a reorganização das equipes ou a adoção de novas tecnologias. Estabelecer metas realistas para o tempo de entrega de produtos ou serviços e monitorar o progresso regularmente. Isso ajudará a identificar a necessidade de ajustes ou melhorias no processo. Investir em treinamento e desenvolvimento de equipes, para que elas tenham as habilidades necessárias para cumprir prazos e entregar produtos ou serviços de qualidade. Utilizar ferramentas de gestão de projetos e colaboração, como Kanban, Scrum ou outras metodologias ágeis, para ajudar a gerenciar e monitorar o progresso dos projetos. Monitorar o desempenho da empresa em relação ao leadtime e buscar continuamente melhorias nos processos para garantir que a empresa continue a cumprir prazos e atender às expectativas dos clientes. Lembre-se que o leadtime ideal dependerá das necessidades específicas da empresa e dos clientes. É importante entender as expectativas dos clientes e ajustar os processos da empresa para atendê-las de forma eficiente e eficaz.
  5. O Jira é a ferramenta de gerenciamento de projeto mais utilizada no mundo, mas nem tudo é muito simples de ser feito com ele, uma função muito utilizada pela metodologia Kanban são as limitações de WIP, porém nativamente nele só é possível ser feito individualmente por coluna, e por ser uma demanda muito forte nessa comunidade resolvi fazer um vídeo de como resolver este problema.
  6. História O Firebird é derivado do código do Borland InterBase quando efetuado abertura de seu código na versão 6.0, mesmo distribuindo o código fonte do InterBase, a Borland anunciou a continuidade no desenvolvimento de versões comerciais do produto. O fato de novas versões serem lançadas com código fonte fechado trouxe desconforto no relacionamento entre a comunidade Firebird e a Borland. Após o lançamento do InterBase 6.5 e 7.0 (ambos comerciais) Alguns programadores em associação assumiram o projecto de identificar e corrigir inúmeros defeitos dá então Interbase 6.0, surgindo aí o Firebird 1.0 em 25 de Julho de 2000. A versão mais recente estável é a 3.0, lançada dia 19/Abril/2016 Baseado em SQL Structured Query Language, literalmente a linguagem padrão para realizar queries. A linguagem SQL é utilizada de maneira relativamente parecida entre os principais bancos de dados relacionais do mercado. Porque Firebird ? Por ele ter nascido por consequência de código desenvolvidos da Borland, e muitos desenvolvedores, utilizavam Interbase como uma versão acessível e conhecida para aplicações Delphi no qual era uma Linguagem da Borland na época. Foi facilmente disseminado entre os desenvolvedores que utilizavam a mesma linguagem, e utilizando dessa ponte, migrando para outras linguagens, que utilizavam o mesmo princípio visual. Um banco de dados de fácil configuração, fácil instalação e arquivo único, até mesmo sem dispor de muita segurança porém em um excelente time de mercado, em uma época onde se predominava, aplicações desktop, no início dos anos 2000, ascensão de um mercado ERP onde se desbravava vários conceitos como serverless, escalabilidades, metodologias, e o que se dizer de um conceito cloud ? A maior preocupação nesta fase, estava na preocupação visual, recém lançado Windows XP, as maiores SofterHouses já existentes no mercado começaram em larga escala a conversão de seus sistemas integrados baseados em DOS, como Clipper e COBOL que não trabalhavam com banco de dados relacional, a maioria apenas arquivos de dados, estavam prestes a perder mercado para SofterHouses que já estavam nascendo apresentando sistemas tão elegantes e de fácil operação como sua plataforma mais popular, Windows XP. Um desenvolvedor cria um banco de dados (e, normalmente, um aplicativo cliente que o acompanha) para instalação em locais remotos. Nestes locais, é natural que ao menos uma pessoa de lá tenha acesso irrestrito ao computador no qual o servidor Firebird será executado - para poder executar tarefas como backup’s e manutenção. Acesso direto aos arquivos permitem que se ganhe acesso completo e irrestrito a toda a informação das tabelas (dados e metadados). Nestes casos, o desenvolvedor pode não confiar que os usuários deste local respeitarão a propriedade intelectual que este banco de dados representa. Então, fica o receio de que o usuário faça a engenharia reversa do banco de dados por interesse próprio, ou que não haja, neste local, uma preocupação real em manter seguros os arquivos a acesso de terceiros. Algo que o Firebird deixa a desejar, seu controle de acesso é simples, e padrão para toda instalação, não existe ainda uma preocupação com seu controle de acesso. E também o Firebird não oferece nenhuma facilidade integrada de encriptação. A resposta simples às questões de segurança é que isto não pode ser feito com as atuais capacidades do Firebird. Se um usuário que tem acesso direto ao arquivo, tem acesso irrestrito às informações dele. Existe apenas uma solução possível para esses problemas, na realidade: Armazenar o banco de dados em seu próprio computador e usá-lo como servidor remoto, para permitir que os clientes conectem ao banco através da internet. Terminal server (Windows ou Linux/Unix) é uma alternativa interessante para implementar esta estrutura. Desta forma, você fica com o controle sobre o arquivo de banco de dados e pode restringir o acesso às suas informações, começa aqui um problema de escalabilidade. Servidor Firebird Embedded Há uma versão especial do servidor Firebird chamada de “embedded”. Esta versão é, na verdade, uma biblioteca cliente especial, que inclui o servidor em si. Quando um aplicativo chama essa biblioteca, ela carrega o servidor e permite acesso direto a qualquer banco de dados acessível ao computador local. Dessa forma, não faz uso do banco de dados de segurança. O nome de usuário especificado durante o “logon” (não existe autenticação de senha) é utilizado para gerenciar o acesso aos objetos do banco de dados (por permissões SQL), mas se este usuário for SYSDBA (ou o dono do banco de dados), então, o acesso irrestrito é possível. As características do servidor embedded são úteis a desenvolvedores que querem criar aplicativos monousuários simples de se distribuir e que não requerem muita segurança. Dessa breve descrição, pode parecer que ter um aplicativo com servidor embedded instalado em um servidor que esteja armazenando outros bancos de dados pode representar um grave risco à segurança. Na realidade o risco não é maior do que se o servidor embedded não existisse. Uma adaptação do modelo Firebird para um mercado Atual Transformando a aplicação como sendo o próprio servidor utilizando de sua configuração Embedded, neste ponto podemos trabalhar com um modelo de aplicação independente e offline, muito utilizado para rodar em SmartPhones. Perfeito para pequenas aplicações que não necessitam de uma alta disponibilidade e um número elevado de usuários, sendo uma excelente escolha para criar catálogos de demonstração de produtos, agendas ou pequenos utilitários. O modelo de servidor Embedded por ser muito leve e permitir ser executado em praticamente qualquer tipo de dispositivo, minimiza os problemas de distribuição e escalabilidade, e configuração das pequenas aplicações, tornando-se a solução ideal para apresentações de software e pequenas aplicações. Aplicações embarcadas têm tido um crescimento relativamente alto, ainda mais com as questões de mobilidade que também estão em alta. Desenvolver uma aplicação embarcada faz com que o seu software seja capaz de ser executado em qualquer tipo de dispositivo, dispensando a instalação, configuração, distribuição de arquivos e muitas outras etapas. A princípio isto parece complicado, afinal imaginando esse cenário, nós já começamos a pensar o que necessariamente devemos mudar ou configurar em nossa aplicação para que seja possível gravar dados em dispositivos portáteis. A resposta para essa pergunta é, nada. Toda a característica de Embedded neste caso concentra-se no servidor de banco de dados, que suporta este recurso. Claro que para desenvolver aplicações embarcadas, poderíamos muito bem fazer a persistência dos dados em arquivos .txt ou .xml ou Json localmente um outro conceito muito mais utilizado para aplicações Mobile é o SQLite, e depois atualizado por API concentrado em um Banco Online com escalabilidade para concentrar todas as informações, com toda segurança exigida atualmente, mas estamos falando de um conceito ainda reutilizado desde os anos 2000 o qual aderiu muito bem o cenário da época. É possível ter escala e fácil usabilidade em bigdata com Firebird ? Apesar de não ser o DB favorito para isso, e nem o mais fácil, para isso, sim é possível, mas se prepare para as dores de cabeça. Seu funcionamento em 64bit foi apenas liberado a partir da versão 3.0, e após isso que apenas estamos conseguindo medir sua performance, em ambientes desse porte, até então pouquíssimas empresas se aventuram em Big Datas, utilizando Firebird, seu sistema de segurança não é dos mais seguros, e seu sistema de integridade de dados menos ainda, é muito comum, trombarmos em rotina de empresas de alta performance, bancos que não tiveram seus commits encerrados adequadamente, quedas de energia, perda de índices corrompidos em sua estrutura de tabela, todos pontos simples na maioria da empresa, mas que derrubam a integridade de seu arquivo, o deixando corrompido, por enquanto nada fora do normal. Para restaurar um banco, Firebird, utilizamos um processo chamado de Backup / Restore, podendo eliminar campos corrompidos, desligando índices obrigatórios, e depois eliminando os registros manualmente, e recuperando todo seu conteúdo restante, mas não é um trabalho dos mais rápidos, já tive experiência de trabalhar com bancos de 10gigas, no qual um processo de backup levou 1hora, e depois o restore mais 1hora, então agora vamos escalar 1h a cada 10g, e chegarmos a um banco de 100gigas, como seria esta realidade?, se sua sensibilidade de corrompimento te coloca em uma prática relativa a este conserto no mínimo 1x por mês, será que ele ainda é viável para sua aplicação ? Evitar a sensibilidade do Firebird, é mais difícil, porém trabalhar no tempo de resposta a sua reabilitação, pode ser o caminho. O Firebird disponibiliza uma ferramenta pouco conhecida ainda entre os fãs deste DB, e ela pode ajudar muito na sua reputação, é o “Backup Incremental”, feita a partir do nBackup, já vi exemplos publicados pela IBSurgeon uma empressa Russa especializada em administração de Firebird, demonstrando bancos facilmente gerenciáveis de 450gigas algo impensável com Firebird, mas os backups incrementais são quebrados, por mês, semana, dia, hora, isso fragmenta seu banco de dados separadamente pela proporção de dados de cada intervalo, quebrando os tamanho, ou seja se vc tiver um corrompimento provavelmente será no intervalo de 1hora que seria onde efetivamente o fluxo de atualização estaria constante, e em um banco desse tamanho, apenas 1 hora de dados, recuperar e levantar isso proporcionalmente a 450gigas, já se torna algo muito mais viável, talvez não para uma aplicação mobile, mas para uma aplicação server, com certeza. Por isso avalie bem, sua necessidade, o que precisa, e porque precisa, a longo prazo, quais os impactos vc causaria a sua aplicação, e a rotina do seu cliente ?
  7. Olá Romário, tudo bem? Eu acredito que sim, mas vou pedir para os organizadores do curso, darem uma prioridade de resposta confirmativa aqui pra vc, ok ?
  8. Olá pessoal, para quem tiver interesse a UNICIV é um dos centros de excelência em tecnologia mais conceituados do Brasil, está disponibilizando os seguintes cursos online e e-books gratuitos: Kanban com Jira https://mla.bs/fa26cd2f Java Spring Boot + Vue.js https://mla.bs/4814b24e Conhecendo a Linguagem C# → https://materiais.estudeti.com.br/ebook-conhecendo-a-linguagem-csharp Teste de Software → https://materiais.estudeti.com.br/ebook-teste-de-software Teste de Invasão em Redes e Sistemas → https://materiais.estudeti.com.br/ebook-teste-de-invasao-em-redes-e-sistemas Gerenciamento de Riscos em Projetos → https://materiais.estudeti.com.br/ebook-gerenciamento-de-riscos-em-projetos Engenharia de Requisitos → https://materiais.estudeti.com.br/ebook-engenharia-de-requisitos Clean Code - Qualidade de código fonte → https://materiais.estudeti.com.br/ebook-clean-code-qualidade-de-codigo-fonte Kubernetes na prática → https://materiais.estudeti.com.br/ebook-kubernetes-na-pratica Aprenda os primeiros comando em SQL e PLSQL → https://materiais.estudeti.com.br/ebook-aprenda-os-primeiros-comandos-em-sql-e-plsql Confira também o canal no YouTube com ótimos vídeos: https://www.youtube.com/channel/UC3ipfMESrstwp6L9X-hP_jw?sub_confirmation=1
  9. Olá Elias Sua realidade não é incomum entre as empresas... Para essas situações, a gente cria configurações para os dois Pedidos Vendas e Compras. Na parametrização do sistema, vc define se ele baixa estoque, no momento do faturamento , ou no momento da baixa do pedido, seguindo a logica de situações. Compras: ABERTO - > APROVADO -> FATURADO -> BAIXADO Aqui algumas empresas utilizam a movimentação de estoque, no FATURADO, quando o Pedido é de "Vendas", e quando o Pedido é de Compras, utilizam a movimentação de estoque, quando o pedido é BAIXADO. Assim vc pode fechar sua lógica facilmente.
  10. Olá Rodolfo Do meu ponto de vista, não é certo. O Certo seria Pagamento em dinheiro de 100,00 e 50,00 no cartão.
  11. Até onde entendi Rodolfo, O Certo seria Pagamento em dinheiro de 100,00 e 50,00 no cartão. Estou entendendo que um crédito loja, pode ser interpretado como um desconto da loja, e isso não é o que ocorreu nos registros de movimentação. O Estorno de um pagamento, gera dinheiro, inclusive se ele tiver pago no cartão de crédito, o estorno vai para a fatura de cartão de crédito dele. Por isso vc não pode considerar esse dinheiro como crédito de loja. O Que expliquei acima, é que as movimentações são independentes, 1 - a Venda abre, e encerra.... sai dinheiro do cliente, entra dinheiro no caixa. 2 - o Estorno abre e encerra... sai dinheiro no caixa, entra dinheiro pro cliente. 3 - Uma nova venda com esse estorno, .... sai dinheiro do cliente, e entra dinheiro no caixa. Mesmo que vc tenha no seu sistema, um módulo que fica salvo lá um valor que o cliente tem de crédito, isso ainda não é considerado um crédito da loja.
  12. Olá Rodolfo Então vamos lá.... Essa nova venda, normalmente é feita com pagamento em Dinheiro mesmo.... vamos entender todo o processo. Efetou 1ª venda, Gerou pedido, baixou pedido, baixou estoque, gerou contas a receber, quitou contas a receber, gerou movimento de crédito no caixa, efetuou deposito na conta corrente. Cliente voltou, fez a devolução, gerou NF de devolução, todo esse processo novamente. Pedido, foi pra cancelado, ou estornado, voltou estoque, gerou contas a pagar....... quitou contas a pagar, gerou movimento de débito no caixa, e retirada da conta corrente. Agora vc tem um crédito flutuante na sua movimentação, devolve o dinheiro para o cliente, ou efetua uma nova venda, e quita com esse dinheiro, fazendo todo o processo novamente. Nessa lógica, isso é dinheiro, e todas as auditorias de movimentação estão registradas.
×
×
  • Create New...