KTachyon

Não foi a primeira. Antes da Microsoft foi a Apple, entre Agosto e Outubro de 2018. Antes da Apple foi a Petrochina em 2007, se bem que essa normalmente não é considerada, porque o valor nunca chegou a ser fixado acima desse valor, apenas houve uma transacção que causou esse trigger. Diga-se de passagem que a Microsoft tem um P/E maior que a Apple (28 vs 16). No entanto, a Microsoft está com o mesmo P/E que a Google/Alphabet, mostrando o quão forte a Microsoft tem estado em relação à Google. Fontes: Petrochina — http://www.nbcnews.com/id/21635325/ns/business-world_business/t/petrochina-worth-trillion-briefly/ Apple — https://www.businessinsider.com/apple-1-trillion-company-stock-2018-8

O PHP é executado no servidor. O JS é executado no browser. Não existe contacto directo entre as duas. O PHP apenas escreve aquilo que é enviado para o browser. O JS executa depois de o browser carregar a página (aquilo que o PHP escreveu). Para teres interacção entre o PHP e o JS, precisas de realizar chamadas ao servidor com, por exemplo, AJAX. E o teu PHP tem que estar preparado para responder de forma apropriada, em vez de despejar uma página web.

Depende. Se estiveres a falar da linguagem de programação para o browser, a vantagem é ser a única linguagem disponível. Não há desvantagens porque não há concorrência nesse aspecto. Se estiveres a falar como linguagem de servidor (Node.js), já depende. O JavaScript é uma linguagem que não utiliza threads, logo não tens situações de concorrência directas. Funciona por eventos, onde não há utilização de recursos quando não existem eventos para processar. A desvantagem é que, se pretendes utilizar grandes máquinas, provavelmente não vais utilizar todos os recursos. Mas se fores utilizar muitas máquinas pequenas (ou lambdas), muitas vezes consegues ter mais performance. Outra desvantagem é que a linguagem é interpretada, como muitas outras linguagens web, e, apesar das optimizações que podem ir aparecendo, nunca conseguirás obter a performance de uma linguagem compilada. Mas essa desvantagem é facilmente combatida com utilização de dependências compiladas para as partes da tua plataforma que necessitem de alta eficiência.

Aquilo que dizes que é "Arranque do servidor informação" é, na realidade, o local onde tratas os pedidos. O código que tens a partir de onde declaras o caminho deve estar dentro desse bloco: //Início do código para o servidor var http = require('http') var url = require('url') var fs = require('fs') var path = require('path') http.createServer(function (pedido, resposta) { var caminho = url.parse(pedido.url).pathname; if (caminho==='/') { var ficheiro = path.join(__dirname, 'public', caminho, 'index.html'); } else { var ficheiro = path.join(__dirname, 'public', caminho); } }).listen(80, 'localhost', function () { console.log('--- O servidor arrancou –--'); }); No entanto, se queres mesmo fazer isto, o melhor é utilizares uma framework tipo express, que te permite organizar melhor as rotas. Se fizeres assim vais ficar com um if/else if gigante. Eu normalmente só uso node para criar APIs e não servidores de html estático. Para isso nginx e apache funcionam muito bem.

Uma coisa é certa. Se um empregador pedir experiência em Linux e tu lhe disseres que tens experiência em Slackware, ele te diz que trabalha com Fedora e tu rejeitas ou dizes que não sabes trabalhar com Fedora, então, nesse case é provável que o empregador não te queira contratar. Tu podes dizer que trabalhas com Slackware, o empregador vai assumir que tens experiência com Linux, independentemente da distro. Agora se tu afirmas que não sabes trabalhar com Fedora, nesse caso o empregador considera que os teus skills são limitados porque não mostras confiança em que consegues fazer uma pequena adaptação.

Eu acho que estás a confundir um bocado. Eu não estou a discordar daquilo que o Rui Carlos, o pwseo ou o M6 disseram. Só estou a expor aquilo que podes contar no mercado de trabalho e que muito do que podes contar só depende da tua capacidade. Por exemplo, podes ser o maior do mundo a usar Slackware, mas se só estiveres à procura de trabalho em Portugal (porque, por exemplo, não dominas a língua inglesa), então a resposta à pergunta do emprego pode passar de “É possível” para “É como encontrar uma agulha num palheiro”.

Eu posso dizer-te a minha carreira. Comecei como um programador, passei por arquitecto de software, CTO e agora sou Team Lead numa empresa internacional. Sou Fullstack. Mal toquei em Slackware, mas já trabalhei com algumas distribuições de Linux, a minha máquina de desenvolvimento sempre foi um Mac (com Mac OS). EDIT: A minha opinião é apenas que não precisas de estudar o Windows para teres emprego. Linux, sim, mas a distro é completamente indiferente.

Faço do primeiro parágrafo do M6 as minhas palavras, pois foi isso que me pareceu ao ler os primeiros posts do OP. Não me vou restringir a Portugal, visto que os skills de que se falam neste fórum são aplicáveis a nível global. Muitos empregadores por esse mundo fora não se interessam pelas preferências de SO dos funcionários. Desses empregadores, um subset não restringe o SO que o funcionário opta por utilizar, desde que seja eficiente no seu trabalho. Ou seja, se consegues arranjar emprego que te permite utilizar Slackware? Definitivamente. Se tens que procurar muito? É possível. Se vais ser eficiente a realizar o teu trabalho? Cabe-te a ti mostrar que consegues fazê-lo. Isto depois de conseguires arranjar emprego. Acho que não há muito mais a dizer sobre isto 🙂

Acho que muita gente vai discordar de que os empregadores não têm razão para usar ou ter alguém com capacidade de utilizar Linux. Repara, hoje em dia quase tudo implica servidores web, quase todos utilizam uma distribuição Linux ou UNIX. Mesmo que te vires para providers como Google, Amazon, Microsoft, IBM, Digital Ocean, Heroku,... todos eles utilizam Linux e UNIX. A própria Microsoft não só fornece o suporte para Linux no Azure, como a sua utilização no Azure está, cada vez mais, a ganhar terreno em relação ao SO da própria empresa. Não só isso, como a própria empresa utiliza o sistema operativo para muitas das componentes críticas da sua plataforma. A aposta da Microsoft no Linux não é uma questão de aproveitamento de tecnologia, mas sim uma questão de sobrevivência. Tendo isto em conta, um empregador que rejeita isto está no mau caminho (estou a generalizar um bocado, mas a longo prazo será sempre inevitável). Agora, relativamente à tua questão, se te deves ambientar com o Linux se queres seguir está carreira? Definitivamente. Se interessa a distribuição que se deve usar? Na minha opinião, não. Qualquer coisa que seja Linux ou UNIX-based irá dar-te a base que precisas. Só tens que escolher aquilo com que conseguires ser eficiente. E não tem que ser uma escolha fixa para todos os sistemas que corres. Podes desenvolver num Mac uma plataforma que vai ser deployed num Docker com Ubuntu como base numa máquina que corre Debian. Os entraves são mínimos.

O problema não é que, na altura do PowerPC não tinhas outras foundries que os pudessem produzir. Estavam presos às decisões, tecnologia e preços que a IBM impusesse. Agora já tens foundries independentes que são capazes de acompanhar e até ultrapassar a Intel no processo de fabrico. Não é como se a Apple não tivesse décadas de experiência no desenho de processadores. Os PowerPC foram desenhamos em conjunto com a Motorola e a IBM, com muitas componentes adicionais como o AltiVec desenhados pela Apple. A ARM foi uma joint venture da Apple com a Acorn e a VLSI. Todos os SoCs de dispositivos móveis, desde o primeiro iPod, foram desenhados pela Apple. Nas últimas iterações desses SoCs tens CPU, GPU e Motion processor tudo desenhado pela Apple. Combinado com a capacidade de integração da Apple, parece-me que só trás vantagens que o desenho dos processadores passe para a Apple. Pelo histórico da empresa, não me parece que apenas faça sentido, mas que sempre foi o plano desde início.

Esse rumor já anda por aí há algum tempo, mas a Bloomberg deve ter tido pistas mais credíveis para ter feito a notícia. Mas eles apontam para 2020, por isso ainda é distante. A Apple já demonstrou que tem talento in-house para desenhar processadores, e não é exactamente uma aventura nova para a Apple, uma vez que já tiveram uma aventura em conjunto com a IBM e a Motorola no desenvolvimento dos PowerPC nos anos 90. Tendo em conta aquilo que tem conseguido com os SoCs dos dispositivos móveis em relação à concorrência, não me parece que fazer isto seja muito surpreendente. Só trás vantagens à empresa, uma vez que passa a ser a Apple a ditar a direcção do desenvolvimento do processador em vez de ter que aguardar que a Intel se queira mexer na mesma direcção.

Não é isso que a notícia diz. As agências e ramos do governo não podem adquirir dispositivos nem utilizar serviços de fornecedores cujo equipamento seja dessas marcas.

A partir do momento em que tu enfraqueces uma feature de segurança para uma entidade, enfraqueces para todos. Não só é um facto, como já está bastante demonstrado em vários casos que já aconteceram no passado. Acabas por não estar a expor a informação de uma má pessoa a uma entidade com autoridade, mas potencialmente colocar a informação de todos nas mãos de pessoas que a vão utilizar com más intenções.

Eu até percebia se fossem "agentes" do Trump, mas como isto já vem desde antes do Trump... E ainda mais ridículo é personalidades como o Peter Thiel e o Bill Gates estarem a favor disto. Ninguém se lembra do fiasco que foi o Clipper chip...

Espero que não tenhas colocado esta notícia porque concordas com o FBI, só porque é a Apple...

Hoje em dia o JavaScript serve para programar frontend e backend e tem uma performance superior ao PHP e é standalone. De qualquer forma não farás tudo em JavaScript. Coisas que requeiram uma aproximação mais nativa irão sempre precisar de uma linguagem compilada como C. Mas são facilmente integráveis em software feito com recurso a JavaScript.

Eu não sou contra a Bitcoin. Sou é contra a forma como é definida como a solução perfeita, quando ninguém tem certezas de nada. Acho que é uma boa experiência... agora é ver até onde é que essa experiência chega.

O pessoal que quer mesmo fazer isto compra máquinas com ASICs por 500€ na Amazon e fica com uma máquina que faz vários TH/s. As gráficas não conseguem competir com isso.

Eu penso que o carlos.portugal tem uma ideia paradisíaca daquilo que é a Bitcoin. Mas a realidade é que a Bitcoin tem os seus problemas (ou melhor, aquilo que não se consegue saber). O modelo da Bitcoin implica mineiros que não estejam associados de forma alguma para que ninguém consiga ter 51% do controlo sobre a moeda. Se isso alguma vez acontecer, essa entidade passaria a ter controlo sobre as transacções e "falsificar" dinheiro. Essa situação parece ser pouco provável, mas só se não se pensar muito no futuro. Sendo a moeda limitada, as quantidades que os mineiros conseguem extrair vai sendo cada vez mais pequena. Quando deixar de ser rentável minar, as pessoas vão, simplesmente, começar a desligar as máquinas. Na realidade, minar não é a única fonte de rendimento deles. Eles também recebem uma parte de um "imposto". As chamadas "transaction fees". Essas são bastante reduzidas em relação ao que o pessoal mina, mas existe uma tendência para crescerem à medida que a moeda vai sendo utilizada. A incógnita é se esse "imposto" será suficiente para reter a comunidade mineira quando acabar a moeda (ou mesmo quando as quantidades que forem possíveis de minar se tornarem suficientemente baixas). Ou seja, a Bitcoin, tal como qualquer moeda, depende de haver um equilíbrio.

A ideia é que tens que ter um endpoint que te devolva dados em vez de fazer o render de um template. Aquilo que tu queres é: res.send(JSON.stringify({ varenviar : varenviar })) E, depois, no pedido ajax, podes adicionar o dataType: dataType: "json", Se queres ter rendering de templates e endpoints para devolver dados, deves tentar separar. Podes, por exemplo, colocar tudo o que é endpoints de dados num path tipo /api/

Não me parece que seja assim que a localStorage deva ser utilizada. A forma correcta é: var clickcount = localStorage.getItem('clickcount'); localStorage.setItem('clickcount', clickcount); A forma como o autor deveria funcionar correctamente em todos os browsers modernos, mas tal não é garantido, pelo que devem ser utilizados os métodos para tal. Ou muito me engano, ou o Storage também estará aí mal. Penso que o que o autor quereria testar era se o localStorage existe e não se o Storage existe. localStorage é um objecto com funções para aceder a um mecanismo que te permite guardar dados no browser do utilizador para o teu domínio. clickcount, da forma como o autor a usa, é uma variável desse objecto, mas essa não é a forma certa de utilização da localStorage. Number é para garantir que o que quer que seja o valor dessa variável, é convertido em número: Number(1) // 1 Number("2") // 2 Number(null) // 0 A localStorage não está directamente associada ao HTML5.

Se fosse só na India...

HTML não é uma linguagem de programação. JavaScript, por outro lado, sim. Não tenho um livro para te recomendar, mas se souberes inglês, a internet está cheia de bons recursos. Também tens que ter uma ideia do que pretendes fazer, porque o JavaScript é, hoje em dia, uma linguagem de programação que te permite fazer muita coisa e tens vários ambientes diferentes em que a podes utilizar.

Tens razão. Estava a ver o tópico no telemóvel, não apanhei o path todo. O problema pode estar no teu app.js, linha 15. Mas sem perceber exactamente o que estás a tentar fazer é difícil de dizer porque está a acontecer.

O node parece bem. A variável path é que não está definida (como diz no erro) na linha 110 do teu RouteInfo.js.