Being paid to test videogames sounds like the perfect job, yeah? But if it was that easy, we wouldn't see (and laugh at) videos like the one below. Hilarious, BTW!
If crackers of all nature are a good concern for testing applications such as Windows, videogame testers have a unique challenge: players are over-stimulated to turn a game upside-down to discover bugs, be it for fun, cheating or fame.
[]s -- AFurtado The statements or testimonies I offer in this post represent my own personal views. I am speaking for myself and not on behalf of my employer, Microsoft Corporation
Ser pago para testar videogames soa como o trabalho perfeito, não é mesmo? Mas se fosse fácil, nós não veríamos (nem riríamos de) vídeos como esse abaixo. A propósito, muito divertido!
Se os crackers de toda a natureza são uma boa preocupação para tester de programas como o Windows, os testadores de videogames têm um desafio único: os jogadores são extra-estimulados para virar um jogo de cabeça para baixo para descobrir erros, seja por divertimento, trapaça ou fama.
[] s -- AFurtado Os relatos e opiniões deste post apresentam pontos de vista pessoais, não refletindo necessariamente a opinião da Microsoft Corporation.
VSX DevCon is a great opportunity to get a deep dive into the Visual Studio extensibility world. I'm really looking forward to attending to the event, which belongs to the fascinating area of providing automation to enable the software factories vision.
Does it get even better? Yes, the event walking distance from my home! :) If you're going to VSX DevCon, drop by for a couple of tea (I mean, a Xbox match) if you will.
[]s -- AFurtado
The statements or testimonies I offer in this post represent my own personal views. I am speaking for myself and not on behalf of my employer, Microsoft Corporation
VSX DevCon é uma grande oportunidade de dar um mergulho profundo no mundo da extensibilidade do Visual Studio. Eu estou olhando ansioso para ir ao evento, que pertence à área fascinante de fornecer a automação para permitir a realização da visão das fábricas de software.
E pode ficar ainda melhor? Sim, afinal dá para ir andando ao evento da minha casa! :) Se você está indo ao VSX DevCon, apareça para tomar um chá (digo, jogar uma partida de Xbox) se você quiser.
[] s -- AFurtado
Os relatos e opiniões deste post apresentam pontos de vista pessoais, não refletindo necessariamente a opinião da Microsoft Corporation.
In a previous blog post, I've embedded a video in which some of the Microsoft perks (fancy name for employee benefits) were presented.
Today, I've found another perk which is not very evident at first but is a very helpful thing: the MSLibrary. In short, through an internal link, any employee can access the digital version of the internal Microsoft Library and check out a book, which is delivered to his/her Office the next day. You can stay with the book as long as no one else is also interested on it, or stay 3 weeks with the copy otherwise.
Reading a technical book is by far the best way to get comprehensive knowledge about a subject. Yes, we have the whole web full of tutorials, code and articles for us to search, but when you want to master something for real, then taking your time to read a specialized book is a champion's approach. Reading the book Mastering Visual Studio .NET 2003 some years ago, for instance, set my path towards extensibility and automation.
Congrats (and thanks) to Microsoft for making a huge knowledge collection available to its employees.
[]s -- AFurtado
The statements or testimonies I offer in this post represent my own personal views. I am speaking for myself and not on behalf of my employer, Microsoft Corporation
Em um post anterior, eu mostrei um vídeo em que algunss dos perks da Microsoft (nome estiloso para benefícios de trabalho) foram apresentados.
Hoje, eu encontrei um outro perk que, embora não seja muito evidente de início, é algo muito útil: a MSLibrary. Em resumo, através de um link interno, qualquer funcionário pode alcançar a versão digital da biblioteca interna da Microsoft e alugar um livro, que é entregue a seu escritório no próximo dia. Você pode permanecer com o livro contanto que ninguém esteja querendo o mesmo, ou permanecer 3 semanas com a cópia de outra maneira.
Ler um livro técnico é uma maneira muito melhor de obter conhecimento detalhado sobre um assunto. Sim, nós temos a web inteira cheia de cursos, código e artigos para nós procurarmos, mas quando você quer dominar algo de verdade, tomar seu tempo para ler um livro especializado é uma abordagem de campeão. Lendo o livro Mastering Visual Studio .NET 2003 certos anos atrás, por exemplo, iniciei meu caminho para a extensibilidade e a automação.
Parabéns (e obrigado) a Microsoft para fazer uma coleção enorme do conhecimento disponível a seus empregados.
[] s -- AFurtado
Os relatos e opiniões deste post apresentam pontos de vista pessoais, não refletindo necessariamente a opinião da Microsoft Corporation.
These days I was asking myself: besides placing XML comments in the code, what an API developer should do so that its consumers (clients) are able to check the API documentation in the Object Browser in Visual Studio or as tooltips when developing the client code, as shown in the pictures below?
The first (obvious) thing is to place the XML comments in the API code, using the Visual Studio “///” (triple slash) feature, which automatically creates the XML skeleton for you to populate:
If your client code is in the same Visual Studio project or solution of the API code, then nothing special needs to be done: the documentation support will be there automagically. However, if the API is being consumed as an external dll, as it is generally the case, something else needs to be done, since the comments are not stored in the .NET assembly. We actually need to enable the generation of XML documentation files in the project properties (as shown below) and make those files available to API clients as well.
When a client adds a reference to such assemblies and its corresponding XML documentation file is there, then Visual Studio is able to build the documentation cache and show it in object browser, code tooltip, etc.
The built-in .NET assemblies (System.dll, System.Data.dll, etc.) are no exception to this rule: if you check your c:\Windows\Microsoft.NET\Framework\v2.0.50727 folder, the XML documentation files for those built-in assemblies will be there as well.
PS: If you want to generate .chm help files from the XML comments, so that your API documentation is even more clear (and navigation-enabled) to your users, I suggest you to use a simple tool I’ve created, that leverages the SandCastle documentation compiler, to easily generate such kind of files.
[]s -- AFurtado The statements or testimonies I offer in this post represent my own personal views. I am speaking for myself and not on behalf of my employer, Microsoft Corporation
Atualmente eu estava perguntando-me: além dos comentários XML no código, o que mais um desenvolvedor de API deve fazer de modo que seus consumidores (clientes) possam checar a documentação da API no Object Browser do Visual Studio ou como tooltips ao desenvolver o código cliente, como mostrado pelas figuras abaixo?
A primeira coisa (óbvia) é colocar os comentários de XML no código da API, usando “///” (barras triplas), que criam automaticamente o esqueleto de XML para que você preencha:
Se seu código cliente está no mesmo projeto ou solução do código da API, nada especial precisa ser feito: o suporte à documentação estará lá automagicamente. Entretanto, se a API está sendo consumida como uma DLL externa, como é geralmente o caso, algo mais deve de ser feito, já que os comentários não são armazenados no assembly .NET. Nós precisamos na verdade habilitar a geração de arquivos de documentação de XML nas propriedades do projeto (como mostrado abaixo) e fazer também esses arquivos disponíveis aos clientes da API.
Quando um cliente adiciona uma referência a tais assemblies e seu arquivo correspondente de documentação XML está lá, o Visual Studio pode construir o cache da documentação e mostrá-lo no Object Browser, no tooltip do código, etc.
Os assemblies que acompanham o .NET Framework (System.dll, System.Data.dll, etc.) não são nenhuma exceção a esta regra: se você verificar o c:\Windows\Microsoft.NET\Framework\v2.0 .50727, os arquivos de documentação XML para esses assemblies internos estarão lá também.
PS: Se você quer gerar arquivos da ajuda .chm a partir dos comentários XML, de modo que sua documentação da API seja ainda mais clara (e com navegação) para seus usuários, eu sugiro usar uma ferramenta que simples eu criei, que usa o compilador de documentação SandCastle, para gerar facilmente tal tipo de arquivo .chm.
[] s -- AFurtado Os relatos e opiniões deste post apresentam pontos de vista pessoais, não refletindo necessariamente a opinião da Microsoft Corporation
A plug-in is an extension to an application that is supposed to be extended, while components doesn't really know their target application.
Interesting analogy: plug-ins extend the behavior of an application the same way as OS device drivers extend the behavior of the OS.
Plug-ins can be self-contained, i.e., they doesn't build on top of each other. On the other hand, they can be designed so that they consume or are reused by other plug-ins.
Plug-ins should be discoverable, not only for the target application but eventually for other plug-ins. This remembers me the VSTS services for registering and un-registering its implemented extensions.
Plug-ins should raise events so that the target app and others plug-ins can properly react.
It's all about extensibility points. There should be contracts (this can be as formal as you want) between extensibility points and extension code.
Entry points (menu items, events, etc.) support extensibility points. That's where the value of having something such as GAT (Guidance Automation Toolkit) is really shown.
Separation of concerns in traditional architectural layers (UI, logic, persistence, etc.) generally is completely orthogonal to the plug-in architecture. Plug-ins are likely to be focused on a specific layer.
Plug-ins should be loaded on demand to improve performance.
Plug-ins help to focus on what's essential to the app and what is optional. Optional items can come in the flavour of plug-ins.
When to not use plug-ins? In small systems with few classes, or in performance-constrained environments.
Should we always provide extension points or only if a client is there to use it? I prefer using the common sense and always provide extension points if I see cool extensibility opportunities, unless that turns to be too cumbersome. It is important to evaluate the trade-off between the overhead of the project versus the overhead of the plug-in infrastructure.
[]s -- AFurtado
The statements or testimonies I offer in this post represent my own personal views. I am speaking for myself and not on behalf of my employer, Microsoft Corporation
Um plug-in é uma extensão a uma aplicação que supostamente deve ser estendida, quando componentes não conhecem realmente sua aplicação-alvo.
Analogia interessante: os plug-ins estendem o comportamento de uma aplicação a mesma maneira que device drivers estendem o comportamento do sistema operacional.
Os plug-ins podem ser independentes, isto é, não se baseiam em demais. Por outro lado, podem ser projetados de modo que eles consumam ou reusem outros.
Os plug-ins devem ser capazes de serem descobertos, não somente pela app-alvo mas eventualmente por outros plug-ins. Isto me lembra dos serviços do VSTS para registar e des-registar suas extensões implementadas.
Os plug-ins devem levantar eventos de modo que a app alvo e outros plug-ins possam corretamente reagir.
Tudo está relacionado a pontos da extensibilidade. Deve haver contratos (tão formais como você quiser) entre pontos da extensibilidade e código de extensão.
Pontos de entrada (entradas de menu, eventos, etc.) suportam pontos de extensibilidade. Isso mostra o valor de ter algo tal como o GAT (Guidance Automation Toolkit).
A separação de interesses nas camadas tradicionais (UI, lógica, persistência, etc.) é geralmente completamente ortogonal à arquitetura de plug-ins. Os plug-ins são geralmente focados em uma camada específica.
Os plug-ins devem ser carregados sob demanda para melhorar o desempenho.
Os plug-ins ajudam a focar em o que é essencial à app e em o que é opcional. Os itens opcionais podem vir na forma de plug-ins.
Quando não usar plug-ins? Em sistemas pequenos com poucas classes, ou em ambientes de desempenho restrito.
Devemos sempre fornecer pontos de extensiblidade ou somente se um cliente está lá a usar? Eu prefiro usar o senso comum e forneço sempre pontos da extensão se eu ver oportunidades interessantes de extensibilidade, a menos que a implementação da extensibilidade traga muito trabalho. É importante avaliar o trade-off entre o overhead geral do projeto contra o overhead da infra-estrutura de plug-ins.
[] s -- AFurtado
Os relatos e opiniões deste post apresentam pontos de vista pessoais, não refletindo necessariamente a opinião da Microsoft Corporation
If you deal with software development you've probably heard that: "It's not a bug, it's a feature!". In other words, the user supposedly was not able to distinguish a given (bad? un-intuitive?) feature from a bug.
But what if the bug is really there and you, magically, are able to turn it into a feature? In a perfect move, EA Sports gave us these an incredible example of how you can turn a bug not only into a feature, but also into an hilarious marketing strategy! Check the video below:
PS: yeah, hiring super-stars sometimes is cheaper than fixing bugs and re-releasing software!
[]s -- AFurtado The statements or testimonies I offer in this post represent my own personal views. I am speaking for myself and not on behalf of my employer, Microsoft Corporation
Se você lida com programação de software você já ouviu provavelmente: “Não é um bug, ele é uma funcionalidade!”. Ou seja, o usuário não conseguiu distinguir uma funcionalidade (mal-feita? pouco intuitiva?) de um bug.
Mas e se o erro está realmente lá e você, magicamente, consegue transformá-lo em uma funcionalidade? Em uma jogada fantástica, a EA Sports nos mostrou um exemplo incrível de como você pode transformar um bug não somente em uma feature, mas também em uma hilária estratégia de marketing! Veja o vídeo abaixo:
PS: pois é, contratar super-stars é às vezes mais barato do que consertar bugs e re-lançar software!
[] s -- AFurtado
Os relatos e opiniões deste post apresentam pontos de vista pessoais, não refletindo necessariamente a opinião da Microsoft Corporation
For those interested in providing a better user experience for manipulating DSLs generated with the DSL Tools, I suggest evaluating the DSL Editor Power Toy (DEPT). It makes it possible for the DSL designer to define rich tree-grid style editors as dedicated views for users to manage the DSL instance under development.
The statements or testimonies I offer in this post represent my own personal views. I am speaking for myself and not on behalf of my employer, Microsoft Corporation
Para aqueles interessados em fornecer uma experiência melhor do usuário para manipular DSLs geradas pelo DSL Tools, eu sugiro a avaliação do DSL Editor Power Toy (DEPT). Ele torna possível para que o projetista da DSL defina editores ricos em estilo tree-grid como visões dedicadas para que os usuários manipulem melhor a instância da DSL em desenvolvimento.
I've just read a blog post from one of the Imagine Cup France 2008 Software Design Invitational winners, from Team Australia, which presented his experience at the world finals with the soak project, focused on sustainable farming.
The way their adventure is narrated gives a taste of how such a competition world finals is special. Incredibly special... Man, I miss those times!
One thing that all Imagine-Cup-teams-to-be out there should really assimilate is how deep the end user involvement is key to a successful project. Check what Team Australia has to say:
"I think the one of the most successful steps in our journey to win was to speak to farmers. We went out to a farm in the country who a team member’s parents were familiar with the owners, talked to the owner and the farm operators to learn first-hand about farming and the problems they are facing."
I've seen this before! v-eye folks (who created the vibrating wristbands awarded by Bill Gates himself) experienced a huge shift towards success after personally interacting with the visually impaired people. And I can give an example by myself as well: Korea winner Waldomiro, the automated learning companion puppet, came to life only after the idea was validated in real schools in Recife, my (now far away) hometown.
Long life to user-centered approaches (and to Waldomiro)!
[]s -- AFurtado
The statements or testimonies I offer in this post represent my own personal views. I am speaking for myself and not on behalf of my employer, Microsoft Corporation
Acabei de ler o post de um dos vencedores da categoria de Projeto de Software da Imagine Cup 2008 na França, da equipe Austrália, que apresentou sua experiência nos finais mundials com o projeto soak, focado na agricultura sustentável.
A maneira que sua aventura é narrada dá um gosto de como tais finais mundiais da competição são especiais. Incrivelmente especiais… Tenho saudades dessa época!
Uma coisa que todos os futuros times da Imagine Cup por aí precisam realmente assimilar é como a participação do usuário final é chave a um projeto bem sucedido. Veja o que a equipe Austrália tem que dizer:
“Eu penso que uma das etapas as mais bem sucedidas em nosso caminho foi falar com os fazendeiros. Nós fomos para uma fazenda no país cujos proprietários eram conhecidos de um dos nossos membros; falamos com proprietário e aos operadores de exploração agrícola para aprender em primeira mão sobre o cultivo e os problemas que estão enfrentando."
Eu já vi isso antes! O pessoal do v-eye (quem criaram pulseiras de vibração premiadas pelo próprio Bill Gates) vivenciaram uma evolução enorme para o sucesso após a interação pessoal com os deficientes visuais. E eu posso dar um exemplo por mim mesmo também: O campeão da Coréia Waldomiro, um fantoche companheiro de aprendizagem automatizado, veio à vida somente depois que a idéia foi validada em escolas reais em Recife, minha (agora distante) cidade natal.
Longa vida às abordagens centradas no usuário (e a Waldomiro)!
[] s -- AFurtado
Os relatos e opiniões deste post apresentam pontos de vista pessoais, não refletindo necessariamente a opinião da Microsoft Corporation
After some "blog vacations", it's time to catch up with the pending blog posts!
In a previous post, I've celebrated the achievement of 50k visitors in FurtaSpace and invited readers to give their feedback and take part in a lottery to win a Windows Live OneCare subscription. The randomly generated winner was Gustavo Andrade, so Gustavo please send me an email to claim your prize!
For those who know my past in technology editions, a disclaimer: no, this is not the same Gustavo (Danzi) Andrade who was (is) my old partner at Imagine Cup Japan 2005, Intel+Berkeley Entrepreneurship Challenge 2006, etc., and now at Microsoft (Canada Development Centre).
For all others, I appreciate your feedback, many thanks!
[]s -- AFurtado
The statements or testimonies I offer in this post represent my own personal views. I am speaking for myself and not on behalf of my employer, Microsoft Corporation
Após algumas “férias de blog”, é hora de tratar alguns posts pendentes!
Em um post precedente, comemorei o marco de 50k visitantes do FurtaSpace e convidei leitores a dar seu feedback e participar em um sorteio para ganhar uma subscrição de Windows Live OneCare. O vencedor sorteado aleatoriamente foi Gustavo Andrade, portanto, Gustavo, envie-me por favor um email para reivindicar seu prêmio!
Para aqueles que sabem meu passado em edições competições de tecnologia, um aviso: não, este não é o mesmo Gustavo (Danzi) Andrade quem era (é) meu velho parceiro da Imagine Cup Japão 2005, o Desafio de Empreendedorismo Intel+Berkeley 2006, etc., e agora na Microsoft (centro de desenvolvimento do Canadá).
Para todos os outros, valeu o feedback, muitos agradecimentos!
[] s -- AFurtado
Os relatos e opiniões deste post apresentam pontos de vista pessoais, não refletindo necessariamente a opinião da Microsoft Corporation.
Microsoft Corporation is looking for new hires in Brazil, for positions in Redmond/USA. It's your chance to join the team! The complete details follow below.
[]s -- AFurtado
The statements or testimonies I offer in this post represent my own personal views. I am speaking for myself and not on behalf of my employer, Microsoft Corporation
A Microsoft Corporation está voltando ao Brasil à procura de novas contratações para posições em Redmond/EUA. É sua chance de juntar-se à equipe! Os detalhes completos seguem abaixo.
[] s -- AFurtado
Os relatos e opiniões deste post apresentam pontos de vista pessoais, não refletindo necessariamente a opinião da Microsoft Corporation
Options are Good.
In life. And in your career.
What fuels your passion?
Core Technical
So, you’ve got your diploma—or you will soon enough. Now it’s time to take on the working world. We know deciding where to start your career can be as nerve-wracking as it is exciting. Maybe you don’t know exactly what you want to do. Maybe you don’t even have a technology background. The good thing is, at Microsoft, you have lots of options. Nowhere else will you have such a variety of products and technologies to get behind—or so many career paths to choose from. You’ll learn from people who have been in the industry for over 30 years. And most of all, you’ll have the resources to reach people all over the world with your work. It’s about taking your career as far as you want it to go—in any direction you choose.
“The variety of products that Microsoft develops greatly influenced my decision to work here. As my career develops I can follow my passion to apply myself to different technologies without having to leave the company.” - David, Software Design Engineer in Test, Live Meeting
Take the Leap, It’s Cool Inside As a Microsoft employee in a full-time technical position, you’ll dive head first into meaningful work. The kind that inspires you. This is the kind of place where your goals are limited only by your imagination and motivation. What’s more, you’ll be backed by a multi-billion dollar company at the top of its game. It’s in your blood to innovate, so join others who share your passion, your talent, and your limitless energy.
"You will find no other company with the sheer breadth of technologies, from Windows kernel, to Office applications, to servers, to Live Web services, to Xbox, to games, to business solutions, to hardware. The things you get to see and learn from other people are amazing." - John, Software Development Lead, Windows Server Performance
Start Here Not sure what full-time position at Microsoft fits you best? Have a look at the Product Development Process to get an idea where your contributions could make the most difference.
Software Development Engineer (SDE) As a Software Development Engineer, you’ll make decisions about design and feature implementation. If you like to write code and design efficient data structures and algorithms to develop next-generation applications or operating systems, this is the position for you.
Software Development Engineer in Test (SDET) As a Software Development Engineer in Test (SDET), you’ll ensure a product’s quality by making sure it performs as users expect it to. Part of the fun is how creative you can be devising ways to manipulate, crush, and sabotage software into submission—while creating innovative testing technologies along the way. Ultimately, as an SDET it’s your input that can make the difference between joy and frustration for the customers. A great SDET demonstrates interest in customer advocacy derived from a holistic understanding of the product from the code level to delivery. Using the tools you create, you’ll pour over source code for trouble spots, debugging and isolating problems, and executing creative tests to find new bugs while regression testing recent fixes.
Program Manager (PM) As a Program Manager, you’ll drive the technical vision, design and implementation of next-generation software solutions. Managing feature sets throughout the product lifecycle, you’ll have the chance to see your design through to completion. Program Managers are advocates for end-users, so your passion for anticipating customer needs and creating outside-the-box solutions for them will really help you shine in this role. As a Program Manager you will have the ability to lead within a product’s life cycle using evangelism, empathy, and negotiation to define and deliver results. You will also be responsible for authoring technical specifications, including envisaged usage cases, customer scenarios, and prioritized requirements lists.
Overall Qualifications:
• Pursuing a BS/MS of PhD degree in Engineering, Computer Science or related field
• 1-2 years experience programming in C/C++/C#, Java and/or other computer programming languages preferred
• Functional level English language skills, written and spoken requirements
Whatever position you choose, you’ll make a real impact in the dynamic world of product development at Microsoft. Microsoft has an ongoing need for exceptional university students and recent graduates from around the world to help us build the next generation of software products. All positions are in the United States at our corporate headquarters in Redmond, Washington.
Send Us Your CV Our recruiting team travels to your region regularly to meet bright and enthusiastic people like you, and we look forward to receiving your CV. And, by the way, we have many positions available, so if there is someone else you think we should know about, please share this information with them.
All positions are at our corporate headquarters in Redmond, Washington, in the United States. We do require functional level English language skills, written and spoken. If we invite you to an interview somewhere in your region, we will cover any travel expenses you may have.
C.V. Instructions
Submitting a C.V. in English is the only way to get to the next stage of consideration, the interview. Here are a few things to keep in mind when you are updating your C.V. to send to us:
• Include your military status if your country mandates it. This will help us know if you are allowed to leave your country to work in the United States
• Clearly state your graduation date, degree/major and the university you attended or are attending
• Specify your technical skills (including programming languages and other development tools you know well), project details (both within university and at any jobs or internships you have held), and technologies you have used on those projects
• Describe your role in the projects that you worked on, and what you personally achieved
• Provide an active e-mail address, physical address, and current phone number where we can reach you
Send it off to: sarec@microsoft.com
A recruiter will review it, and if interested will set up a phone interview as a first step!
NOTE: All non-U.S. residents will require a U.S. work visa (H1B). If you receive an offer from Microsoft, we will cover all costs for visa processing and approval.
Microsoft is an equal opportunity employer and supports workforce diversity.
Strumenti 
Guida
