Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | para garantir o tal "employment" em Portugal, nada melhor que...
nao e' C, nem C++, nem C#... mas sim CunhaTechnology! |
| | | | | Nem sempre isso funciona se depois não souberes ocupar o teu lugar, mas sabedoria conciliado com uma boa cunha num sítio fixe é sempre outra coisa e pode-te ajudar muito (impulsionar-te para o futuro) na tua vida profissional/financeira, bem como aprenderes muitas coisas que numa empresa mais pequena talvez nunca viesses a aprender.
I'm a lost soul in this lost world... |
| | | | Pode ser que desta saltem pontos de vista diferentes :))
-- "Muda, que quando a gente muda, o Mundo muda com a gente" -- Gabriel, o Pensador |
| | | | Desculpem, isto era a resposta à thread de baixo.. ando a dormir :(
-- "Muda, que quando a gente muda, o Mundo muda com a gente" -- Gabriel, o Pensador |
| | | | Tu tens uma empresa que geres há uns anitos e um filho. Admitindo que o teu filho não é a desgraça da administração, porque não irá ser ele o futuro administrador e não um terceiro? Essa das cunhas só se aplica quando é para fugir à lei, porque de resto é ridículo. Se há oportunidades, burro é quem não as apanha, e ter um familiar ou amigo que nos pode empregar é uma oportunidade.
Dominus vobiscum
"I may have invented control-alt-delete, but Bill Gates made it really famous", David Bradley, IBM Engineer |
| | | | Ja nao sei onde ouvi isto, mas ca vai : "EUA e' a terra das oportunidades, e Portugal a dos oportunistas!" lol... |
| | | | Sim e?
Dominus vobiscum
"I may have invented control-alt-delete, but Bill Gates made it really famous", David Bradley, IBM Engineer |
| | | | Talvez aquela seja uma boa frase para demonstrar porque é que nós somos o que somos numa Europa como esta e o que ainda somos menos num Mundo como este!
I'm a lost soul in this lost world... |
| | | | ?!?! Que tem de mal ser oportunista, isto é, aproveitar as oportunidades? Tá tudo maluco? E mais, que tem isso a ver com a nossa posição enfraquecida na Europa?
Dominus vobiscum
"I may have invented control-alt-delete, but Bill Gates made it really famous", David Bradley, IBM Engineer |
| | | | Que tem de mal ser oportunista, isto é, aproveitar as oportunidades?
Tá tudo maluco?
E mais, que tem isso a ver com a nossa posição enfraquecida na Europa?
Não acho mal que se aproveitem as oportunidades, caso as tenhamos, o que acho mal é, nalgumas situações, essas oportunidades serem dadas a pessoas com menor capacidade que outras. Dou-te um exemplo: uma câmara municipal, abriu concurso público para uma funcionária administrativa. Concorreram várias pessoas, muitas delas com cursos superiores na área, e vasta experiência de trabalho em funções similares. Pensarás tu: "Muito bem, se concorrer uma pessoa com o 12º ano incompleto, terá dificuldade em conseguir o lugar". E, num panorama normal e correcto, pensas bem. Mas o que aconteceu não foi isso, quem ficou com o emprego foi a tal pessoa com o 12º ano. Não quero com isso dizer que essa pessoa tenha menos capacidade de trabalho que as outras, mas o facto é que tem. O tempo que se demora a "ensinar" essa pessoa para os serviços que terá de efectuar é muito superior aquele que seria necessário nas ouras candidatas.
José Carlos aka The_X Há pessoas que perdem tempo a criar assinaturas decentes! Eu não! |
| | | | Deves pensar que quase todo o pessoal que acaba o curso tem um pai empresário, dono de uma empresa que o pode empregar. Se pensarmos assim paro ja de estudar, o meu pai tem uma empresa e aqueles 'burros' que andam na faculdade a lutar para ter boas notas e perceberem mais e mais, sao 'parvalhoes' pq tudo nao passa de futilidades. Nao. Se andas na faculdade e tens um pai empresario que te vai dar o 'tacho' optimo, mas nao sejas egoista ao ponto de pensar que os teus amigos que tem melhores notas que tu e sabem efectivamente mais que tu também tem um paizinho que vai dar emprego. Igualdade de oportunidades... algo de básico que devias dar mais atençao na Minha opiniao.
Be different, think for yourself. |
| | | | Se há oportunidades, burro é quem não as apanha, e ter um familiar ou amigo que nos pode empregar é uma oportunidade. Pena que nessas "oportunidades" geralmente se escolham pessoas independentemente do mérito e do valor pessoal. É certo que em empresas "familiares" a questão não se põe, mas agora em empresas maiores a maior parte das vezes as cunhas traduzem-se em injustiça sem a mínima justificação. E se tu achas que num estado de Direito e se numa sociedade que se diz justa arranjar emprego seja uma função das ligações/conhecimentos e não do mérido, então és mais um oportunista. |
| | | | Eu não desvalorizo o mérito porque é, indubitavelmente, parte fundamental no percurso de um cidadão enquanto trabalhador mas não existe per se porque não é essa a lei da vida. Podes ter muito mérito e seres um bom trabalhador, mas se na vida não fores esperto e não deres as machadadas no momento oportuno, então não passarás apenas de um bom trabalhador com um percurso interessante. Infelizmente é assim, aqui ou no mundo. Agora, se tenho uma empresa que o meu pai me convida para lá trabalhar, independentemente de ser, ou não, o mais adequado, vou recusar? Quem disse que eu não poderei ser o mais adequado depois, mesmo que à partida não tenha tanto mérito como outro? São termos muitos subjectivos, mas sinceramente não tenho nada contra em agarrar as oportunidades que a vida nos dá e que, geralmente, advêm também do mérito.
Dominus vobiscum
"I may have invented control-alt-delete, but Bill Gates made it really famous", David Bradley, IBM Engineer |
| | | | Isso é o que eu chamaria de "monarquia empresarial"... E o filho "não ser a desgraça da administração" não quer dizer que seja o melhor candidato. E quem avalia isso? O pai?
Por alguma razão em empresas públicas teóricamente é necessário um concurso para aceder a vagas. Claro que apesar da intenção da lei, muitas vezes o jogo está viciado...
------------------------------------------- "All great truths begin as blasphemies." George Bernard Shaw |
| | | | Como as Câmaras Municipais, conheço cada trolha que entrou lá por cunha na área da informática, apenas sabe fazer umas coisitas em photoshop e fazer o que qualquer mortal faz =) "Foi cunha, foi cunha, foi cunha.." :-D
I'm a lost soul in this lost world... |
| | | | Olá :-) Não há garantias de "Employement", quer seja agora sabendo 9 áreas e com montes de experiência quer seja no futuro. A maior parte dos programadores americanos e os europeus também estão a sentir isso pois já estão a ser "dispensados". Na ásia, mais concretamente na India, por 1/4 do valor do ordenado de um programador americano, as empresas têm o mesmo trabalho feito, por excelentes e dedicados programadores indianos. Claro que o saber não ocupa lugar, e é sempre melhor vermos uma luz do que estar na "idade das trevas", mas daí a isso garantir em Portugal o trabalho a alguém, acho que só mesmo na função pública.
. . . A inteligência tem limites, a estupidez não. . . . |
| | Hmm? (Pontos:3, Informativo) |
| | Isto não é repetido?
-- "Muda, que quando a gente muda, o Mundo muda com a gente" -- Gabriel, o Pensador |
| | | | | É repetido sim senhor. O Bladerunner não deve ter reparado (ou pesquisado) que o artigo já tinha sido publicado há 11 meses! Quando li o título tive logo a sensação que já tinha lido um artigo semelhante (pelos vistos, o Bladerunner não teve a mesma sensação). Também passado 11 meses acho que é sempre bom reciclar uns artigos. Acho que vou propor um sobre linguagem sobre sms -Sab "Um mundo melhor é deixado como um exercício para o leitor, Paul Graham"
|
| | | | O que me leva a perguntar.... "isso já recebe sms?" ;) Não pude resistir, é certo!
//vd |
| | | | Acho que ainda não manda, mas está quase, quase. Sabes, "há piores". -Sab "Um mundo melhor é deixado como um exercício para o leitor, Paul Graham" |
| | | | - Object-Oriented Programming
- Java, C++, C#, VB.NET
- Design Patterns
Parece-me algo... repetitivo... Sou apenas eu? -- Luís Bruno |
| | | | | Repetitivo porque ? OOP != Java/C++/C#/VB.NET != Design Patterns. "I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | Conto as linguagens como sendo a implementacao de OOP; se eu "sei" OOP, devo conseguir pegar em qualquer uma dessas linguagens. O "Design Patterns" (o livro) sempre me pareceu um repositorio de codigo C++. -- Luís Bruno |
| | | | Eu sou sempre um céptico no que toca a estas coisas das "tecnologias do futuro" porque normalmente acabam por focar-se sempre na moda do momento e não pensar no que realmente é central. Um belo exemplo é o XML que ultimamente parece que tem de ser enfiado em tudo e mais alguma coisa sob pena de não se parecer suficientemente "cool" e avançado (não é que não seja importante, mas já enjoa). Dito isto, há uma passagem no artigo que devia ser logo o ponto 1: Cultivate Curiosity Finally, (and yes, I realize this is No. 11), the most important skill you can acquire is curiosity. Try things out. That new language or new technology may or not be important to you in your present or future job; but not everything you learn needs to be job-focused. Don't be afraid of failing; it's always difficult to be a beginner at any new technology. Most failures happen because people expect too much of themselves too fast. Be satisfied with small steps, and don't let time (or the absence of it) get in your way. Instead, make time to look at, research, and test new development techniques and tools. Isto falta a muita gente, e pior ainda, parece não abundar nos futuros Engenheiros Informáticos que começam cedo a refugiar-se no facilitismo e a considerar a aprendizagem extra-curricular como uma perda de tempo. Pessoal que definha e morre se não usar o debugger do Visual Studio (fala quem já passou pela experiência de ver gente a fazer debugging de programas destinados a correr em Linux, em Visual Studio, porque em Linux "não existem debuggers gráficos"(!)) ou que diz não saber nada de HTML(!!) e se refugia no Frontpage(!!!)...
-- Carlos Rodrigues |
| | | | | Tinhas que vir lembrar a regra aqui no tasco. Para providenciar um outro data point, tenho colegas em Sistemas Operativos que nao sabem declarar variaveis. Em C. Isto antes da frequencia. Apos dois semestres com a dita linguagem... Hell, eu ja' meti o DDD debaixo do nariz de um grupo; depois de o usarem dois minutos, resolveram voltar para o MS Visual Studio. Onde nao conseguem inspeccionar o valor de uma variavel (digamos que no DDD e' intuitivo) -- Luís Bruno |
| | | | Debugger do Visual Studio presta para alguma coisa ? Nunca o usei, mas mandaram-me um output dele, e tinha la uns erros, o que nao sugere nada de bom ! Debugger decente é o SoftIce, e agora (para algumas coisas, nao todas) o OllyDBG. Para Linux, o gdb lá aguenta o serviço, mas nao é nada de especial ! (saquem o gdb init do Mammon, que é bastante bom :))) ). Uma coisa que detesto no Linux é o facto de nao termos uma feature tipo Windows, de breakar numa função de sistema ou API tipo um strcpy. Alias, até existe um debugger (o PIKE ou coisa parecida, que faz isto, mas so para drivers...).
Mister ToniDosImpostos "O software é como as mulheres, se não sabes, não MEXAS !" (c) ME, 2004! |
| | | | Para Linux, o gdb lá aguenta o serviço, mas nao é nada de especial ! Realmente não estou a ver porque dizes isso, o gdb é até bastante potente, com uma curva de aprendizagem bastante acentuada mas potente (para isso é que existem os frontends gráficos...). Uma coisa que detesto no Linux é o facto de nao termos uma feature tipo Windows, de breakar numa função de sistema ou API tipo um strcpy. E isto é necessário para... É claro que fala alguém que recorre ao debugger apenas quando os planetas estão alinhados... o cérebro é normalmente uma opção preferível ao gdb.
-- Carlos Rodrigues |
| | | | O gdb comparado com o Softice ou ate mesmo o OllyDGB, acredita que nao é muito funcional. O init do Mammon, torna aquilo um bocadinho melhor, mas mesmo assim, ainda precisa de evoluir. A aprendizagem, nao tem nada de especial, é pegar no manual, ler aquilo e pronto. Breakar numa API, é necessario para analisar codigo no qual nao tenhas a source (ah... deves ter sempre a source, eu nao :)). Ou entao, uma aplicacao daemonized, ou com threads, etc etc etc. Podes dizer que fazes o attach a um PID, o problema, é saberes qual dos processos é o que te interessa. Breakas numa função da API e as probabilidades aumentam muito. Para finalizar, deves ser mais um génio que resolve problemas a olhar para o código (lá está, tens acesso à source), e raramente precisa dum debugger (és descendente do cavaco ???). Também nao cometes overflows nem nada dessas mariquices né ? Bem me queria parecer...
Mister ToniDosImpostos "O software é como as mulheres, se não sabes, não MEXAS !" (c) ME, 2004! |
| | | | Para finalizar, deves ser mais um génio que resolve problemas a olhar para o código (lá está, tens acesso à source), e raramente precisa dum debugger (és descendente do cavaco ???). Também nao cometes overflows nem nada dessas mariquices né ? Bem me queria parecer... Não me considero um génio mas por acaso resolvo muitos problemas a olhar para o código, até porque prefiro pensar no que estou a fazer em vez de atirar toda a merda para cima do compilador e resolver os erros (i.e. programar à cão). Também apanho a minha conta de segfaults e como sou um fã da biblioteca ElectricFence só preciso de recorrer ao gdb para fazer um backtrace. Logo considero o debugger uma ferramenta útil mas raramente necessária. O debugger é uma ferramenta para quem pensa no que o código faz em vez no que o código é suposto fazer. Agora essa do acesso à source... Eu cá pensava que estavamos a falar de fazer debugging a código... Dá lá um exemplo desses em que não tenhas acesso à source.
-- Carlos Rodrigues |
| | | | É muito simples, analisar um rootkit por exemplo. Nao tens acesso à source, nao tens debugging symbols, etc etc, ou seja, nao tens a papinha feita, logo a coisa complica-se. E neste caso o GDB não é muito util, ou melhor, nao é tao bom como poderia ser (pior seria se nao existisse nenhum!). O design do linux (ptrace) também nao facilita nada a tarefa, o que torna este tipo de debugging muito mais complicado. Muitas vezes lá tem que se recorrer ao IDA para disasm a coisa e ter algum sentido. O problema, é se temos código encriptado, packed e tal, onde breakar na API é bastante valioso. Ok, também posso dar o braço a torcer e admitir que o GDB foi pensado para debug source code e portanto nao ter outras features. Na altura, o GDB serviu para o que precisava, mas tive que desbravar caminho e arranjar soluções para as features que faltavam.
Mister ToniDosImpostos "O software é como as mulheres, se não sabes, não MEXAS !" (c) ME, 2004! |
| | | | Chamas a isso debugging? Debugging é, por definição, eliminar bugs/depurar código. Não depuras código sem o código. O que estás a falar não é debugging, é desassemblagem/reverse engineering. O problema, é se temos código encriptado, packed e tal, onde breakar na API é bastante valioso. Ph34r 7h3 1337 hax0r!
-- Carlos Rodrigues |
| | | | A palavra reverse engineering é proibida pelas EULA ;) Depois, podes eliminar bugs sem teres o codigo original, ou ate podes mesmo adicionar features a um programa, sem o codigo original (mayb3 th4t's t00 l33t f0r u ???). Esse l33t h4x0r so mostra como és mais palerma do que queres fazer querer aqui. Nunca viste codigo encriptado ou packed ?
Mister ToniDosImpostos "O software é como as mulheres, se não sabes, não MEXAS !" (c) ME, 2004! |
| | | | A palavra reverse engineering é proibida pelas EULA ;) Não em Portugal. Depois, podes eliminar bugs sem teres o codigo original, ou ate podes mesmo adicionar features a um programa, sem o codigo original (mayb3 th4t's t00 l33t f0r u ???). Ohh, que útil... Não deves ter mais nada para fazer mesmo... Esse l33t h4x0r so mostra como és mais palerma do que queres fazer querer aqui. Nunca viste codigo encriptado ou packed ? Volta a ler o que escreveste...
-- Carlos Rodrigues |
| | | | As EULA's nao sao validas em Portugal ? Weird... Ja agora, da uma vista de olhos pelo site da PJ, pode ser que alteres essa ideia do RE ;)
Mister ToniDosImpostos "O software é como as mulheres, se não sabes, não MEXAS !" (c) ME, 2004! |
| | | | As EULA's nao sao validas em Portugal ? Weird... São, incluindo aquela cláusula no fundo que diz que algumas partes da EULA podem não ser aplicáveis em alguns países... Ja agora, da uma vista de olhos pelo site da PJ, pode ser que alteres essa ideia do RE ;) E a ti remeto-te para os artigos 6º (direitos do utente) e 7º (descompilação) do regime de protecção jurídica dos programas de computador (Decreto-Lei nº 252/94). Este decreto-lei é uma transposição de uma directiva comunitária por isso o direito ao reverse-engineering por descompilação com fins de interoperabilidade e a determinação dos principios de funcionamento de um programa por observação do seu funcionamento não só são permitidos em Portugal como em toda a UE.
-- Carlos Rodrigues |
| | | | Alguem falou em funcionamento ? Estamos a falar de patching. Nao me parece que pelo facto de patchar um bug ou adicionar funções, a empresa vá ficar muito contente.
Mister ToniDosImpostos "O software é como as mulheres, se não sabes, não MEXAS !" (c) ME, 2004! |
| | | | | Ja agora qual EULA é que tem essa exclusao ? Acabei de ler 3 da M$ e nao vejo lá nada...
Mister ToniDosImpostos "O software é como as mulheres, se não sabes, não MEXAS !" (c) ME, 2004! |
| | | | Da EULA do Windows 95: "(...)You may not reverse engineer[...]except and only to the extent that such activity is expressly permitted by applicable law(...)". Além do mais os contratos não podem incluir cláusulas que contrariam a lei.
-- Carlos Rodrigues |
| | | | eu é mais prinf prá li e prá acolá :)) uma aternativa pouco profissional e muito pouco eficiente, sem dúvida, mas que resulta :)) quando tou mesmo enrascada utilizo o gdb, mas é mais para ver onde craschou, LibFence é fixe para testar o alocação de memória.
___________________________________ (linooks (at) zmail (dot) pt) |
| | | | uma aternativa pouco profissional e muito pouco eficiente, sem dúvida, mas que resulta :)) Isto é o que se ouve por aí e devo dizer que está completamente errado. Os printfs aliados ao uso do cérebro e ao ElectricFence deixam poucas razões para o uso de um debugger. O mal é que muita gente, quanto confrontados com um erro, correm para o debugger e põem-se a correr o código linha-a-linha e a acrescentar remendos à medida que vão avançando. Isto é horrível e raramente dá bons resultados, é muito melhor pensar sobre os erros no contexto do problema (com um pouco de prática nisto acaba-se por olhar para o debugger como um obstáculo que só faz perder tempo).
-- Carlos Rodrigues |
| | | | Provavalmente é porque o assembler te faz alguma confusao ;) Quem tiver prática, dá com muitos erros rapidamente num debugger.
Mister ToniDosImpostos "O software é como as mulheres, se não sabes, não MEXAS !" (c) ME, 2004! |
| | | | Provavalmente é porque o assembler te faz alguma confusao ;) Quem tiver prática, dá com muitos erros rapidamente num debugger. Nada disso. Essa de dar com os erros num debugger é questionável. Os erros aparecem e se precisas mesmo do debugger para descobrir a sua causa é porque o problema que estás a tentar resolver está a escapar do teu controlo. Não digo que em algumas situações o debugger não seja útil mas deve ser encarado como o último recurso para evitar o vício. O uso regular do debugger leva normalmente à preguiça mental e apesar de os viciados nele jurarem a pés juntos que descobrem os erros mais rapidamente eu digo que, na realidade, deixam chegar mais erros à fase de debugging porque confiam que o debuger estará lá para os salvar. Só a confiança no nosso próprio cérebro pode levar a que consigamos produzir centenas de linhas de código com quase zero erros, simplesmente porque os identificamos logo na fase da codificação. E é inquestionávelmente mais produtiva a concentração na programação do que a alternância entre o editor e o debugger.
-- Carlos Rodrigues |
| | | | falo disto sem conhecimento de causa, mas parece-me que sem um debugger não se testa o kernel... estou errado? ---
Que Bush vos abençoe. |
| | | | | Um debugger não serve só para correr código linha a linha. Uma das formas de o usar até é conceptualmente semelhante a utilizar output. Com uma diferença: se estiveres a correr o programa e de repente descobres que precisas de inspecionar mais uma coisa em que não tinhas pensado ainda, não tens de terminar o programa, editar, compilar e voltar a correr até ao ponto onde tens o problema. Com o debugger, limitas-te a adicionar mais um breakpoint ou watch. Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | A discussão acerca dos benefícios/vicios dos debugger fez-me lembrar um post do Linus Torvalds na lkml: "I happen to believe that not having a kernel debugger forces people to think about their problem on a different level than with a debugger. I think that without a debugger, you don't get into that mindset where you know how it behaves, and then you fix it from there. Without a debugger, you tend to think about problems another way. You want to understand things on a different _level_. [...] Because I'm a bastard, and proud of it!"
-- Carlos Rodrigues |
| | | | É uma teoria. Pessoalmente, tendo a acreditar que o debugger é uma ferramenta útil como forma de colmatar a tendência dos seres humanos para cometer erros ao implementar algo que está conceptualmente correcto. E embora acredite que a atenção aos detalhes desvia frequente e indevidamente a atenção de uma perspectiva mais global, não acredito que a utilização de um debugger contribua mais para isso do que a utilização de outras técnicas de depuração como output. O problema não está nas técnicas que se usam para localizar e compreender um erro. Está na mentalidade do programador quando chega à altura de decidir como o corrigir.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | A particularidade da técnica do output (i.e. táctica dos printfs) é que é chata e obriga a pensar no local exacto onde fazer esse output, o que obriga a pensar no código conceptualmente de forma a não perder tempo com printfs mal localizados e execuções sem resultados. No fundo os printfs actuam como forma de disciplina mais do que como forma de obter informações úteis acerca do estado do programa (quem usa esta técnica regularmente acaba por se dar conta disto).
-- Carlos Rodrigues |
| | | | Esse mesmo conceito de disciplina também aplica-se à forma como colocas breakpoints no código, se não quiseres perder tempo inútil com depuração step-by-step. Eu prefiro usar printfs para output de entradas e saídas nos módulos funcionais do meu código, e a depuração com breakpoints para detalhes de implementação no interior desses módulos. Plexar. |
| | | | e a depuração com breakpoints para detalhes de implementação Tal como eu já dizia, o debugger leva ao excesso de atenção aos detalhes da implementação. O pensar acerca do bug em vez de o caçar com um debugger leva a que de um só golpe se eliminem mais bugs, mesmo antes de eles se revelarem. O ataque com o debugger é o remendo e não a prevenção.
-- Carlos Rodrigues |
| | Ou... (Pontos:3, Interessante) |
| | - RSS/RDF
- Grid Computing
- Aspect-Oriented Programming
- Python
- XUL
- Bayesian Learning
- Business Patterns
- SVG
- Embedded Linux
- XQuery/XPath
|
| | | | | O meu comentário (apenas às primeiras 5, o tempo escasseia)-- basicamente parecem-me tecnologias que existem agora mas ainda com pouca expressão (em termos comerciais), mas que podem vir a ser dominantes no futuro, embora falar no futuro seja sempre arriscado: o que é hype hoje pode não ser amanhã, e algo que, mesmo não sendo hype, parece ser um paradigma tecnicamente superior (aop, por exemplo), pode vir a ser ignorado no futuro (apesar disso). # RSS/RDF Que é isto? Aquele xmlzinho que é serve para transportar as news dos sites? hmm.. acaba por encaixar na big-picture do xml, como mais um formato, e não me parece que alguém mantenha o emprego por saber isto... # Grid Computing Actualmente (ainda) não tem grande expressão. A oracle lançou há uns meses a série 10g (g de grid) e parece-me que é a unica empresa a comercializar "grid" hoje em dia, com o senão que ninguem usa 10g. Para o futuro sim, para já não ajuda ninguém a manter o emprego. # Aspect-Oriented Programming Fala-se muito nisto como o próximo OOP, mas quando se tenta rotular demasiado uma coisa, acaba por dar merda. A ver vamos, para já tb ainda não tem grande expressão (em termos de mercado), mas já há projectos engraçados: AOP para java http://www.eclipse.org/aspectj/ # Python Give me five!! Mas tb acredito que neste momento python não garante emprego a ninguém. Acredito piamente que cada vez há-de ter mais adesão e ser mais usado mesmo comercialmente.embora seja muito dificil a adopção de tecnologias no mundo comercial sem uma grande empresa por trás. O python vai ter mesmo que ser numa filosofia de "ver para crer", i.e. chegar ao chefe de um departamento que gastou 40 mil contos durante 6 meses a fazer uma app de merda em .net cheia de bugs e dizer "aqui uma versão funcionalmente equivalente; python; 3 semanas; 1/6 do bloat code". Mas mesmo assim é dificil. # XUL Que é isto? Aquela cena usada no mozilla? Se é não conheço bem. |
| | | | # XUL Que é isto? Aquela cena usada no mozilla? Se é não conheço bem. Pelo que tenho lido o XUL é potente (mais correctamente, a plataforma mozilla é potente). Tem o problema de muita gente não fazer a mínima ideia que existe e estar demasiado associado ao browser (o que provoca uma reacção "plataforma mozilla? HAHAHA!"). Este artigo é ilustrativo da tecnologia que está lá por baixo e também dá para ficar a saber onde é que o pessoal do mozilla andou a gastar o tempo (se bem que talvez a plataforma e o browser devessem ser projectos separados em vez de tentar transformar o mozilla - suite - numa espécie de SO...).
-- Carlos Rodrigues |
| | | | Acho que a IBM, a HP e mais uns dedicados ao clustering também comercializam grid. O Python? Ao que parece, a Nokia vai suportar primeiro o Python e a seguir Perl.
"No comments" |
| | | | basicamente parecem-me tecnologias que existem agora mas ainda com pouca expressão (em termos comerciais), mas que podem vir a ser dominantes no futuro Precisamente. Ao contrario das anteriores q são dominantes agora mas q no futuro terão pouca expressão. # RSS/RDF Que é isto? Aquele xmlzinho que é serve para transportar as news dos sites? hmm.. acaba por encaixar na big-picture do xml, como mais um formato, e não me parece que alguém mantenha o emprego por saber isto... BitTorrent and RSS Create Disruptive Revolution # XUL Que é isto? Aquela cena usada no mozilla? Se é não conheço bem. Remote Application Development with Mozilla Cumprimentos Mario Valente |
| | | | Precisamente. Ao contrario das anteriores q são dominantes agora mas q no futuro terão pouca expressão. Ainda estou para ver como e' que "bayesian learning" e "business partners" podem ser consideradas tecnologias, ou mesmo aspectos que possam garantir emprego a seja quem for... mas... "I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | Damn! "business patterns" e' o que queria dizer. "I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | O "bayesian learning" tambem me deixou confuso. Redes neuronais? Que serao usadas para...? Mas isso junto aos "Business Patterns"... Acho que o plano do Mario para o futuro e' escrever um software que compila os padroes de utilizacao, queixas, e pedidos mais frequentes, pesa-os e ordena-os por relevancia, livra-se dos clientes "esquisitos", cria os produtos que os outros querem, faz o telemarketing, aprende a atender chamadas de apoio a cliente, e podemos ir todos para casa ;) |
| | | | O bayesian learning tem neste momento aplicações q vão desde a filtragem de spam até ao processamento do genoma humano. No futuro terá aplicações possíveis em campos q vão desde o routing de pacotes até à construção de desktops q "aprendem" as necessidades do utilizador. As business patterns não são mais do q uma aplicação mais pratica, mas importante, das design patterns. No entanto, ao inves de se determinarem patterns de baixo nivel (tipo Singleton, etc) trata-se de determinar patterns com aplicação pratica nos negocios. Isto será tao mais importante no futuro quando se consideram coisas como o Business Process Outsourcing ou o ebXML/UBL/BizTalk. Sao portanto tao "tecnologias" qto as design patterns ou as regular expressions, mas a um nivel mais "alto" e por isso com mais importancia futura. Cumprimentos Mario Valente |
| | | | Nao digas isso sobre o bayesian learning; o ultimo gajo que vi a dizer a mesma coisa numa lista de mail foi flamed ate' `a exaustao ;) A filtragem anti-SPAM, pelo menos nos dias que correm, usam classificadores idiotas ("naive bayesian classifier") em vez de aprendizagem. A diferenca basica e' que nos classificadores nao ha aprendizagem de nada, ja tens todos os dados; o classificador usa um set de dados categoricos, e calcula a distribuicao dependendo da proporcao dos dados inseridos. Por outras palavras, e' um metodo de analise de frequencia, e para muita gente cai no no reino da estatistica "classica". A aprendizagem, por outro lado, tenta criar relacoes entre os dados para prever o que vem a seguir, e e' um metodo de analise preditiva. Ate' onde sei, e' um conceito "hot" em redes neuronais. |
| | | | Boas. "Mas tb acredito que neste momento python não garante emprego a ninguém." Dá uma olhada durante uns tempos às propostas de emprego do Google, por exemplo. @809, Nbk
|
| | | | Em http://www.google.ch/intl/en_ch/jobs/, por ordem de menção a linguagens, aparece (nos dois perfis), o seguinte: Strong C/C++ programming skills. 3+ years Java web application programming experience, 5+ years industry experience. Experience using SQL including some database design. Experience with Python, C++, Javascript desired. *Uma* menção a python, a par de js e c++, e num perfil que se chama... "java software enginner"!! Definitivamente não é representativo. Seja como for existem exemplos melhores e mais antigos: a ericson tem software desenvolvido in-house, pelo menos desde 1999, todo em python. Devem haver N empresas nesse mundo fora que façam do python o seu principal foco. O ponto não é esse: o python neste momento não "tem massa" porque não é aceite de forma generalizada. É uma questão de métrica. |
| | | | | devem tar a gozar com o ppl o conhecimento de javascript e flash podem garantir um trabalho (vulgo projecto), mas um emprego ??!!! Pagava para ver
___________________________________ (linooks (at) zmail (dot) pt) |
| | | | | Quanto?
------------------------------------------- "All great truths begin as blasphemies." George Bernard Shaw |
| | | | Eu tenho uma visão um pouco diferente. Ao que parece essas tecnologias estão todas en vougue ou seja, apesar de existirem mais empregos disponíveis também vai existir mais competição, o salário será mais baixo já para não falar dos indianos que se parecem dar muito bem com as tecnologias da microsoft e no unix com a combinação lamp. O que não quer dizer que essas sejam inválidas, muito pelo contrário. Aqui fica a minha combinação de tecnologias/temas/qualidades: 1 - Curiosidade por novas tecnologias 2 - Inteligência artificial(HOT!!) 3 - Ada 4 - Cobol 5 - Arquitectura de computadores 6 - Sistemas operativos(device drivers, design e desenvolvimento de... etc) 7 - Assembly(mips/arm/x86) 8 - Programação orientada a objectos/aspectos 9 - Meta programming 10 - Bons conhecimentos de management na área de TI. Trolling: Se forem só e apenas o gajo que percebe mto de computadores e entretanto não tiverem outro tipo de competências estão condenados a ser o tipo de gajos que chega aos 30 anos com um esgotamento pq antes não teve coragem de dizer ao patrão NÃO quando ele lhes pedia para fazerem mais horas :P Aqui a estratégia é esperar que os programadores mais experientes comecem a pedir a reforma e deixar que o os mais novos se entretenham com os novos brinquedos. Entretanto, vai haver sempre e durante muito tempo necessidade de programadores com competências nestas áreas e um maior investimento na área da inteligência artificial. My job went to India and i all got was this lousy t-shirt |
| | | | | Não concordo com algumas das coisas que apontaste:
O Ada é pouco relevante. Apesar da sua importância em algumas áreas é basicamente um "who cares?" no curriculum.
O Cobol é um dinossauro. Tal como o Ada não impressiona ninguém (e tal como este não é muito excitante para uma auto-aprendizagem).
Assembly é muito importante mas apenas como uma forma de conhecer a máquina e não como algo que se considera usar na prática fora de alguns casos restritos.
A meta programming (tipo aquela coisa com os templates do C++)... bem, do que tenho visto não passa de uma curiosidade com utilidade duvidosa.
Quanto aos conhecimentos de management, é difícil decidir se o importante é ter conhecimentos de gestão ou simplesmente ter bom senso (coisa que muitas pessoas parecem não possuir).
No final tudo se resume a ter bom senso, curiosidade e vontade de aprender. Não adianta ter conhecimentos daquilo que alguém acha que é importante se outro tipo com muito mais conhecimentos de base e vontade de aprender consegue adquirir esses conhecimentos num curto espaço de tempo e depois aplicá-los com muito mais eficácia.
-- Carlos Rodrigues |
| | | | No final tudo se resume a ter bom senso, curiosidade e vontade de aprender. Não adianta ter conhecimentos daquilo que alguém acha que é importante se outro tipo com muito mais conhecimentos de base e vontade de aprender consegue adquirir esses conhecimentos num curto espaço de tempo e depois aplicá-los com muito mais eficácia. Concordo ctg. Em relação ao Ada e Cobol, a vantagem é mesmo ja ninguem lhes ligar nenhuma. Se ninguém se interessa menos competição vais ter. Para além de que o Cobol ainda é utilizado no mundo dos negócios e o Ada na industria militar, aeronautica, etc... são nichos que vale a pena explorar :) Em relação ao assembly, é a mesma história. Ha-de ser sempre preciso alguém que mantenha todas aquelas abstracções que facilitam a vida ao programador, alguém que mantenha as máquinas virtuais, os compiladores, que exprema um pouco mais a velocidade disto ou daquilo. Se os outros programadores preferem nem lhe tocar, so tens é de agarrar a oportunidade e tornares-te um crack. Emprego não te vai faltar... Mas sim, o mais importante é conseguir saltar de tecnologia em tecnologia sem que o processo seja um grande fret. |
| | | | Para além de que o Cobol ainda é utilizado no mundo dos negócios e o Ada na industria militar, aeronautica, etc... são nichos que vale a pena explorar :) Claro, mas no entanto não passam de linguagens como outras quaisquer. Um tipo que domine as bases e tenha conhecimentos num leque mais ou menos vasto de linguagens aprende Ada ou Cobol em dois dias. No entanto o caso do Cobol é problemático porque não é tanto a linguagem como os sistemas que foram desenvolvidos nela e esses não se aprendem facilmente pois não são coisa de fácil acesso, acabando quase invariavelmente por ficar do domínio de programadores formados ainda no período Silúrico... Assembly já não é bem assim, é preciso saber pensar como a máquina. Pode dizer-se que é preciso aprender assembly para usar assembly :)
-- Carlos Rodrigues |
| | | | My job went to India and i all got was this lousy t-shirt
esta assinatura esta' genial!! |
| | | | Podes sempre comprar uma n este sitio ... |
| | | | Provavelmente podem-se resumir a 5 (por ordem decrescente de importancia): - J2EE,
- BEA | WebSphere | Jakarta/Tomcat | JBoss,
- OOP/OOD + Design Patterns (colapsados em um),
- Web Services (XML-RPC, SOAP, etc.),
- Oracle | SQL Server | MySQL,
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | Que engraçado, ninguém falou das que eu uso para me manter empregado... Que tal perl, mason, php, bash (hi hi hi). bash e companhia limitada é um mundo! Como já muitos disseram e bem, o que interessa é estar motivado, ter vontade de aprender e acima de tudo, não ter medo de novos desafios ou de encarar novas tecnologias ...
----
Conclusão: Iogurte sem caroços não tem espinhas |
| | | | | | Por acaso :P mas é mais pros lados de uma Rã que dizem ser um SAPO! =) hihi
I'm a lost soul in this lost world... |
| | | | Eis aquilo que eu acho que serve para manter/mudar de emprego (para criar é outra história), relacionado com IT. De notar que a lista foca apenas aspectos tecnológicos e não sociais, como ter uma grande lábia, dar graxa, etc... nem pseudo-psicológicos, como inteligência emocional, foco, motivação ou a tal curiosidade já mencionada acima (mais correctamente: avidez de conhecimento). Cada pessoa deve ser muito boa a dois ou três items, não se espera que ninguém seja um ás a tudo (se diz que é, o mais provável é que seja um zero a tudo). - programar: saber programar é como saber escrever correctamente, só que o nosso interlocutar é um pedaço manhoso de silício com um vocabulário algo reduzido. Saber programar bem é meter esse manhoso a trabalhar bem, e quem o sabe fazer, como dizia o meu pai, merece um beijo no rabo cheio de merda. Linguagens "das massas": java & .net suite (o resto é cu). Linguagens de nicho: C, ada, cobol. Linguanges de suporte: perl, shell scripting (& unix related stuff, sed, awk...)
- unix: deixem-se de merdas! Já lhe diagnosticaram a morte um dezena, ou perto, de vezes, e ainda anda por cá... desde há mais de 30 anos! E vai continuar. Unix é a forma mais pragmática de lidar com os manhosos.
- xml & related: o xml é mais que tags a abrirem e fechar com uns atributos estúpidos lá dentro. É toda a paranóia de software, especificações and shit related, como xpath, xquery, schemas, dtds, xsl, xsd, bla bla bla... i.e. dados + software para manipulá-los. Há que viver com isto (nota: soap já vem incluido, mas não dispensa a consulta dos prospectos)
- tcp/ip, http, web services: a forma mais pragmática, hoje em dia, de meter os manhosos a comunicaram.
- arquitectura de sistemas: os manhosos precisam de estar bem acomodados para trabalharem bem...
- SQL e motores (oracle,etc): parecido com as razões do xml, dados e SW para os manipular... só que em grande escala.
- SEGURANÇA: é precisar preservar os manhosos de mãos alheias.
|
| | | | | Muito bem :) Há alguma maneira de dar pontuação interessante e engraçado ao mesmo tempo?!
Este comentário foi publicado ao abrigo de leis internacionais "How to handle a Troll". |
| | | | | Se não tens cunhas e não fores funcionário público a melhor forma de manter um emprego é ser-se versátil nas novas tecnologias. Ajuda saber XML, Java, C#, etc... mas daqui a uns anos isto não chega. Agora se tiveres a capacidade de te integrares rapidamente numa nova tecnologia e o teu patrão ( ou chefe ) souber disso, dificilmente te despedirá. Eu programo 99% do tempo em Java e por vezes uso XML, mas já tive necessidade de mexer em AWK, perl, C#, C++, entre outros... a diferença é que quando surge essa necessidade, eu não viro as costas ou crio problemas. Simplesmente, parto um pouco pedra e resolvo o problema. Outra ajuda, é termos auto-formação 100% do tempo. A universidade acabou para muitos, mas a aprendizagem ainda só agora começou. Lá porque programamos em Java e gostamos de java, nada impede de conhecermos minimamente outras soluções. Ser perito em tudo é impossível, mas conhecer minimamente diversas tecnologias é fácil e tem o seu gozo.
|
| | | | | Talvez seja estupido colocar esta questão, pelo que lamento desde já a minha ignorância. O meu professor de tecnologias vai começar a leccionar programação orientada a objectos (com C++ ou java), no âmbito do clube de informática lá da escolinha. Do ponto de vista do mercado de emprego (pessoalmente ia para o C++...) o Java bate o concorrente mais directo, certo? Tenho que ver se influêncio o professor na escolha, pois estou agora confrontado com a necessidade de mergulhar para o mundo de trabalho... hard times. "We a "We all know Linux is great... it does infinite loops in 5 seconds." --Linus Torvalds |
| | | | | Pessoalmente, o Java é uma melhor linguagem para incutir nos alunos o paradigma OOP. Depois de compreenderes o paradigma podes aprender as caracteristicas especificas do C++.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
|