Jump to content

pwseo

Staff
  • Posts

    1,677
  • Joined

pwseo's Achievements

unsigned user

unsigned user (4/5)

  • 10 Years
  • Solver Bronze
  • Voter Bronze
  • Voter Silver Rare
  • 1 Year

Recent Badges

244

Reputation

34

Community Answers

  1. Ao já referido pelo @nunopicado acrescentaria o seguinte: será boa ideia planear o fluxo do programa em papel antes de o transcrever para código. Durante essa fase de planeamento, deve ser especificado o tipo de dados e o significado de cada variável (apenas e só um por cada variável). O problema seria assim auto-evidente: não só Quer_Sobremesa_1 nunca seria do tipo de dados Integer ou Real (mas sim Boolean, para representar um valor dicotómico Sim/Não), como seria impossível reutilizar variáveis -- pois obrigaria a dar duas funções/significados a uma variável durante o planeamento referido.
  2. Saudades de quando as pessoas faziam páginas em HTML e CSS! Ainda que pouco prático para produção de conteúdo em massa, havia sempre algum toque pessoal, e tudo funcionava mais rapidamente.
  3. Como verificaste que os dados não são guardados? E como estás a utilizar essas funções?
  4. Boa iniciativa. Na realidade, penso que seja complementar às reproducible builds, dado que se dirigem a problemas diferentes (que fazem parte de um todo assustador, infelizmente). De facto é uma pena suportar apenas Go. A longo prazo, será mais difícil suportar esta ferramenta do que a iniciativa da GNU previamente falada, dado que na primeira teremos que constantemente actualizar a análise estática de todas as linguagens, enquanto que na segunda «basta» assegurar a verificação de hashes, independentemente do significado do código.
  5. E possivelmente só resolveram porque os computadores se recusaram a trabalhar; se fossem apenas as pessoas, nada mudaria. No meu local de trabalho tivemos na semana passada temperaturas de 30-31ºC dentro dos gabinetes, e as coisas só foram resolvidas quando a viabilidade das vacinas armazenadas foi colocada em causa pelas altas temperaturas -- enquanto eram apenas utentes que se sentiam mal ou trabalhadores sujeitos a condições de trabalho indecentes pouco se fez. Tipicamente português.
  6. @klasss Estavas (estás?) a confundir várias coisas. O problema reside no facto da tua variável input ser um elemento HTML <input>, e não a string que representa o texto nele escrito (à qual podes referir-te através da propriedade/atributo .value). Assim sendo, quando estavas a invocar o método .replace, obtinhas o erro de que tal função não existe -- pois a mesma só existe quando aplicada em strings. Portanto, primeiro tens que extrair o texto do <input> e só depois operar no mesmo: var input_element = document.querySelector("#codigopostal"); // elemento <input> var input_text = input.value; // texto contido no <input> var cp_semtraco = input_text.replace(/-/, ""); Saliento a importância de perceber a diferença entre input_element e input_text nesse exemplo (que são, respectivamente, um Element e uma string). Tenta novamente para ver se já conseguiste resolver o problema.
  7. Agora, tendo em conta o que falámos, consegues facilmente escrever uma função em PHP que faça o pretendido. Experimenta. Existem pormenores que não estão completamente correctos na solução que deste, mas tornar-se-ão evidentes no código.
  8. @klasss A tua questão tem pouco que ver com Laravel propriamente dito, e muito de programação pura. Diria que o ideal será definires claramente o que pretendes que a tua função faça, e depois a implementes. Sugiro um breve exercício em pseudo-código para não estares limitado pela sintaxe da linguagem. função Gerar Número de Processo inputs ultimo_n: número do último processo gerado ultimo_ano: ano do último processo gerado ano: ano actual logica ... Consegues completar a secção «lógica» com base nos inputs e na descrição que fizeste do resultado esperado?
  9. Qual o tipo de dados de input? Se é o resultado de uma document.querySelector, provavelmente input não é uma string, e como tal, não tem o método replace. A que elemento HTML deste o id #codigopostal? Se for um elemento <input>, então podes referir-te ao texto nele contido através da sua propriedade value: var foo = input.value.replace(/* ... */);
  10. Assumindo que não estás a cometer um erro por diferenças entre os nomes das variáveis (ie. CP_semtraco e cp_semtraco são nomes diferentes), poderás estar a ter problemas com o scope da variável. Como referiu o @Ivo Vicente, será necessário forneceres um pouco mais de contexto para compreendermos melhor qual o problema, dado que isoladamente a regexp utilizada faz o que se pretende -- o que significa que o problema está noutro lado.
  11. Desde há cerca de 2 anos e meio que tenho vindo a utilizar o openSUSE, concretamente a sua variante Tumbleweed. Quando escolhi esta distro houve alguns factores que me influenciaram: queria experimentar algo diferente de Ubuntu/Debian, Arch ou Gentoo (e já tinha utilizado Fedora há muito tempo atrás) achei interessante ter uma distro que fosse rolling-release (no meu caso, tem mais benefícios que prejuízos) achei interessante que todas as releases sejam testadas de forma automatizada via openQA achei interessante ser uma distro com suporte maduro para btrfs e snapshots sempre ouvi dizer que o zypper (package manager do openSUSE) era dos melhores -- e de facto, a libsolv (que o zypper utiliza para resolução de dependências) está a ser adoptada também noutras distros, a mais conhecida das quais Fedora (no seu dnf) Até agora, tenho estado satisfeito. Considero um equilíbrio interessante entre bleeding-edge e estabilidade (provavelmente pela combinação referida de ser rolling-release com testes automatizados via openQA). Existem sempre alguns pequenos problemas relacionados com a utilização de software muito recente... mas habitualmente são de resolução rápida. O que mais me incomoda nesta distro (além dos updates gigantescos se deixarmos passar mais de 2 semanas sem actualizar) acaba por ser o facto de que o resto do mundo utiliza derivados de Debian, Fedora, ou Arch. Tudo o resto são pequenos nichos, e nem sempre o software é lançado para SUSE/openSUSE... o que implica alguma ginástica com ficheiros .deb e .rpm. Mas com iniciativas tipo Flatpak e AppImage isso é cada vez menos frequente.
  12. Não me parece (infelizmente) que vá ter um crescimento muito grande, até porque está fortemente ligado à cultura GNU, com muito pouca permissividade para software non-free (apesar de todos podermos definir outras fontes de software, claro...), o que impõe uma barreira adicional num sistema que, pelo seu fundamento, já é de nicho. Há uma alternativa actualmente mais utilizada (penso eu): o NixOS. No entanto, o pessoal do Guix tem feito aquele esforço adicional para reduzir ao mínimo possível o grau de confiança que tens que ter desde o início do teu sistema (a última tentativa deles reduziu isso a um binário com 357 bytes, todos eles devidamente documentados, a partir dos quais toda a restante toolchain e sistema são eventualmente compilados do código). Mais ligado à minha área, já tenho visto alguns investigadores (ligados à programação, claro), a investir tempo no Guix para maiores garantias de reprodutividade das investigações que conduzem: um passo além da típica abordagem de uma imagem Docker com software bloqueado em determinadas versões. O futuro dirá 🙂
  13. E já agora, uma apresentação interessante sobre o problema referido pelo Ken Thompson aplicada ao mundo das criptomoedas (ou para a computação na generalidade, embora as criptomoedas sejam um tema particularmente sensível): Bitcoin Build System Security
  14. O autor faz link para um outro post de sua autoria no qual por sua vez faz ligação para o artigo Reflections on Trusting Trust do Ken Thompson: uma leitura rápida e muito interessante. Faz-nos pensar duas vezes sobre a fiabilidade do software (e hardware) que utilizamos. A cada dia que passa dou mais valor a iniciativas para reproducible builds (p ex. Debian, GNU Guix).
  15. @plynyo, Parece-me que estás a abordar o problema na sequência errada. Se não sabes ainda qual a diferença prática entre um interpretador e um compilador nem qual utilizar para o teu projecto, diria que primeiro precisas de te informar bastante sobre o assunto. Muito concretamente, antes de tentares fazer uma linguagem para outras pessoas aprenderem a programar, já precisas de saber fazer linguagens simples, que não será utilizada por outras pessoas, para teres uma ideia dos domínios envolvidos (lexing, parsing, árvores sintácticas, etc etc etc). Já existem linguagens interessantíssimas para quem está a dar os primeiros passos na programação (como referiste, e bem, Python é um bom exemplo). Para considerares fazer mais uma linguagem para que outros utilizem, é necessário que identifiques claramente os pontos fracos das que já existem e de que maneira a tua nova linguagem irá melhorá-los. Exemplificando: se considerarmos que um dos problemas de Python é a falta de exercícios com algoritmos e estruturas de dados, será que vale mesmo a pena fazer uma nova linguagem? Seria necessário fazer os exercícios e além disso criar toda uma nova linguagem. Não seria mais simples investir esse esforço em criar exercícios para Python? É difícil atingir o equilíbrio entre adicionar complexidade suficiente para tornar a linguagem útil vs remover complexidade suficiente para tornar a linguagem simples/divertida para programar; há linguagens que lutam há anos e anos para serem bem sucedidas nesta frente, e são esforços de décadas de várias pessoas. Não quero com isto desencorajar-te de criar uma nova linguagem (muito pelo contrário), apenas considero demasiado ambicioso o objectivo de criá-la para ensinar outras pessoas a programar (pelo menos para já). Ainda assim, recomendo vivamente que cries várias pequenas linguagens para resolver problemas concretos e treinar nos diversos aspectos que estão envolvidos na criação de linguagens de programação (interpretadas ou compiladas). Existe um óptimo livro online para te meteres no assunto, se quiseres: Crafting Interpreters.
×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.