D ??????????????

このポストは、10 月 6 日に投稿された D-Series Performance Expectations の翻訳です。
新しい D シリーズの VM は、高速なローカル (一時) ストレージまたは CPU を必要とするアプリケーションで優れたパフォーマンスを実現します。ただし、最適なパフォーマンスを得るためには、システムが構成されるしくみについて多少理解することが重要です。
クラウドは共有環境であるため、VM の大半は 1 つ以上の他の VM とサーバーを共有しています。1 つの VM が共有リソースを妥当な分量以上に使用することを防ぐため、VM が利用できる仮想 CPU のコア数、RAM、ローカル ディスクの容量、IO スループットには VM の種類に応じて制限が適用されています。これらの制限により、すべてのユーザーがシステムから一貫性の高い予測可能なパフォーマンスを得ることができます。
新しい D シリーズには、VM の種類に応じてローカル SSD に以下のようなコア数と RAM が割り当てられ、容量およびパフォーマンスの制限が適用されています。

…(read more)

CppCon Videos Available

In case you missed CppCon or attended but missed a few sessions (or want to review), videos for most of the talks are available on You Tube . There is plenty there for developers of all experience and temperament including:

C++ in Microsoft Office: How Microsoft Uses C++ to Deliver Office Applications Across Windows, Apple, Android, and Web Platforms ( part II ), Zaika Antoun

From the Dropbox Trenches: A Deep Dive into Two Cross-Platform Mobile Apps Written in C++ , Steven Kabbes…(read more)

Facebook Syndication Error

This feed URL is no longer valid. Visit this page to find the new URL, if you have access: <a href=”https://www.facebook.com/profile.php?id=306705402722523″>https://www.facebook.com/profile.php?id=306705402722523</a> …read more…(read more)

??? ????? Imagine Cup 2015!

Конкурс Imagine Cup продолжается практически круглый год, поэтому уже сейчас пришла пора задуматься о том, какой проект представить на конкурс в этом году. В то время как мы проводим серию хакатонов Imagine Cup по всей России, чтобы помочь студентам придумать и реализовать свою идею, регистрация на конкурс уже открыта, и некоторые интересные международные конкурсы уже начались!

image

Как будет проходить конкурс в России?

В этом году, как и в прошлом, финал конкурса пройдет в США. Россия представит на международном этапе конкурса лучшую команду, которая будет отобрана на национальном российском финале соревнований в Москве весной 2015 г.

Прием заявок на конкурс продлится до февраля 2015 г. (точную дату мы объявим дополнительно), после чего мы определим оптимальный формат проведения регионального отбора команд для участия в национальном финале. Заявки можно подать уже сейчас онлайн, заполнив соответствующую форму на сайте http://www.imaginecup.ru.

Соревнования, как и в прошлом году, проводятся в трех категориях: игры, инновации и социальные проекты.

Международные онлайн-соревнования

Как и в прошлом году, вы можете участвовать также в ряде международных онлайн-конкурсов, соревнуясь сразу с командами и участниками со всего мира. Эти конкурсы устроены таким образом, чтобы помочь вам на каждом этапе развития проекта – участвуя во всех конкурсах по очереди, вы в конце концов создадите действующий прототип своего продукта. Онлайн-конкурсы отражают основные этапы развития проекта:

  • Конкурс видеопитчей предполагает, что вы хорошенько продумали идею своего проекта и можете изложить её в коротком видео
  • В конкурсе Project Blueprint требуется описать ваш проект по некоторому шаблону, чтобы убедиться, что вы продумали все основные составляющие проекта, такие как целевая аудитория, бизнес-модель, или геймплей игры.
  • Конкурс прототипов предлагает вам разработать более детальное представление проекта и его внешнего вида и информационной архитектуры. Вам необходимо представить такие документы, как storyboard или user flow diagram.

Набор требуемых материалов слегка различается для каждого из основных конкурсов (игры, инновации и социальные проекты). Подробности можно почитать на международном сайте соревнований.

Конкурс Code Hunt Challenge

В рамках Imagine Cup также есть соревнование, предназначенная для тех, кто ищет легкие пути. В этом соревновании легко поучаствовать, потратив всего полчаса времени, и при этом вы приобретете полезные навыки и получите удовольствие. В прошлом году таким конкурсом был Brain Games, в этом году мы представляем совершенно новый индивидуальный конкурс – Code Hunt Challenge.

В рамках Code Hunt вы работаете в рамках специального тренажера, в котором вам показывается фрагмент ошибочно-работающей программы на C#. Вам необходимо найти в программе ошибку и исправить её так, чтобы она выдавала требуемый результат. Начиная с очень простых заданий, конкурс постепенно становится всё более захватывающим…

Соревнования Code Hunt проводятся раз в месяц в течение двух суток в третьи выходные месяца (по гринвичскому времени). Это значит, что ближайшие соревнования пройдут 15-16 ноября. В другие дни вы можете подготовиться к соревнованиям пройдя пробные упражнения на сайте www.codehunt.com.

Imagine Cup – конкурс и образовательная программа

Важно отметить, что Imagine Cup – это не просто конкурс, который проходит весной и летом каждого года. Это еще и образовательная активность: хакатоны, онлайн-курсы по технологиям и предпринимательству, вебинары и много другое. Это активность длиною в год, которую надо начинать прямо сейчас. Регистрируйтесь в группе Imagine Cup вконтакте, чтобы быть в курсе активностей, следите за новостями в блоге, будьте активны и будьте счастливы!

How we do Pair Programming

Our team is responsible for developing and maintaining all of Azure Management SDK which includes quite a bit of languages and tool. For example, we own .NET SDK (https://github.com/Azure/azure-sdk-for-net), PowerShell Toolset (https://github.com/Azure/azure-sdk-tools-pr), Java SDK (https://github.com/Azure/azure-sdk-for-java), Node JS SDK (https://github.com/Azure/azure-sdk-for-node), XPlat CLI Toolset (https://github.com/Azure/azure-sdk-tools-xplat), PHP SDK (https://github.com/Azure/azure-sdk-for-php), as well as a pretty complex internal code generation platform. That being said we are a rather small team and until recently had at max 1-2 devs expert in each language/platform. That obviously presented a few issues. To gain maximum efficiency our PMs would always have to give us a diverse mix of tasks that included all of the languages and platforms. Whenever there was a big event such as //build or TechEd and the deliverables piled up (usually PowerShell and XPlat CLI got hit the worst) some team members had to work late hours while others were not really able to help. Also the daily scrums were kind of boring, since people could not really relate to what everyone else was doing.

So, to make the long story short, we have discussed at our last retrospective that our team would probably benefit from doing XP style pair programming (we have recently moved into an open space and the room setup was congruent to pairing). Since we didn’t have any XP practitioners on our team I have shot an email to our in-house Agile guru Arlo Belshee (http://arlobelshee.com/) who has generously agreed to come over to coach our team.

Here is what we have decided to do:
1. Do 2 pairing sessions a day – 90 minutes in the morning and 90 minutes in the afternoon. This arrangement gives us enough time to answer emails and review GitHub pull requests while letting us have 100% focus during the pairing sessions. By the way, pairing is intense. Doing 8 hrs a day of straight pairing will fry your brain!
2. Use the thinker/typer approach for coding tasks (not sure what is the official XP name for this) – one person types and one person thinks. The one typing is not allowed to type on his/her own. The moment the typer wants to contribute he/she needs to push out the keyboard. If both people want to “think” they need to discuss. This is by far the best pairing strategy we’ve found, which prevents the person who is not typing from falling asleep.
3. Change partners every session. That works for us.
4. Change work items every session. One person from the pair stays on the work items (if it takes more than 1 session to complete the item) and the other should go. Another rule is that a person can’t stay on a single task for more than 2 sessions!
5. Picking the right pair – initially we’ve agreed to do a mix of an expert with someone new to the area. For example someone who knows PowerShell pairs with a Java guys on a PowerShell task. This enables for the fastest knowledge dissemination. Later on, as the knowledge becomes more even, so will the pairs get more even.
6. Use the whiteboard to track work items and tasks. Before the session begins we write down all work items that are up for pairing on the board and discuss which exactly steps need to be done. The people volunteer for pairs and the names are written down on the board next to the items. Finally as work gets done, the tasks get crossed out one by one.
7. Pick easily “pairable” items, expanding the set of “pairable” items as we go. Here is a diagram that Arlo drew:
 
Initially we took just small simple coding problems that we knew how to solve while keeping a more complicated items for individual work. As time went by we started picking more complex items as well as non-coding research tasks. The goal is to make all work items “pairable”.
8. Do a brief retrospective on Tuesdays and Thursdays to micro-adjust our new process

So far we’ve been doing this approach for 3.5 weeks and based on the team feedback its working great for everyone. By the way, if you are going to try pairing, make sure to try pairing for the entire month before making the decision (Arlo’s suggestion). The first few days you will see a dramatic improvements. The 2nd – 3rd week you may start to hate it (the brain will rebel against someone always telling it what to do and will just shut down). The 3rd – 4th week is when you will get into the rhythm and will wonder how you were able to code without a partner before.

So here is where we are today. The team is now able to work on literally any codebase. Some quotes from the retrospectives have been “this is the most fun I’ve had coding in the past 6 months”, or “I have learned in one session more than I have learned in a long time being stuck doing X”. By the way, as you may imagine the main fear of our PMs has been that while we are learning and stuff we would stop delivering as many story points (2 people on 1 keyboard). The reality has been quite the opposite. We’ve started pairing in Sprint 39 and have finished more points than in Sprint 38. Now we are in Sprint 40 and have one week left to go. Based on velocity chart we should be complete if not more than at least as many story points as in the last sprint. Also our flow (we’re doing a mix of Scrum and Kanban) has become much more even. We max a max of 4-5 items in Active state, as opposed to 10-15 in the past.

So overall I would say this has been quite a successful experiment. Feel free to post comments or email me if you’d like more details on how pairing is working out for us.

Installing and Debugging Drivers with Sharks Cove Hardware development board

We asked our talented intern, Steven, to work on several hardware projects this summer and he agreed to share some of his experiences with Windows hardware development using Sharks Cove hardware development board through a series of blog posts. Below is his first blog detailing his experience installing and debugging a driver using Sharks Cove.

Sharks Cove is a hardware development board that you can use to develop hardware and drivers for Windows. The Intel Sharks Cove board supports driver development for devices that use a variety of interfaces, including GPIO, I2C, I2S, UART, SDIO, and USB. You can also use the Sharks Cove board to develop drivers for cameras and touch screens.

For information about the Sharks Cove board, see www.sharkscove.org

For details about Windows compatible hardware development boards, see www.msdn.microsoft.com/hardwaredevboard

Here’s the blog in his own words.

 

In this post, I wanted to provide more of a walkthrough on the process of setting up a Sharks Cove for installing and debugging a driver. This post is a direct result of my experience working with the board. Currently, there is a step-by-step guide to setting up and using Sharks Cove on MSDN, so I will not cover everything in detail. Instead, I’d like to look at each of the steps and provide the details of my experience.

Sharks Cove setup

You can absolutely skip this section if you have the board already setup and provisioned or the link above is sufficient. This section is merely to provide clarification from my experience setting up the board. Starting from the top, you will need to gather your hardware. My setup was as follows:

  • A monitor accepting DVI input
  • An HDMI cable and HDMI-DVI adapter
  • A powered USB hub
  • USB MouseKeyboard
  • USB Ethernet adapter for network access
  • USB to micro USB cable for kernel debugging

After initial setup, it is possible to get away without a monitor for the Sharks Cove as you can simply remote into the machine from your host machine. The next step involves setting up your host machine. I think the documentation for this section covers it. You simply need Visual Studio Express, which is free, if you don’t already have it. Then, you’ll need to download and install the WDK 8.1 Update. This kit installs all of the necessary files to write drivers for Windows 8.1 Update, 8.1, 8, and 7. The kit is integrated into Visual Studio so you can develop and deploy drivers from within Visual Studio. My experience with this integration was positive. In general, the workflow is very fluid when compared to debugging separately through WinDbg or KD.

Now, we have arrived at setting up the Windows Image and installing it onto the dev board. To me, this step looks overwhelming, but I assure you that it is fairly simple and the documentation has you covered. Once you have successfully created an image, keep it around on a USB in case you ever need to reimage the board. The documentation directs users to download Windows Embedded 8.1 Industry Pro Evaluation. This is a trial OS option for available to developers, but in my experience, the board can run any version of Windows client image you want to install.

Next we need to provision the target system. In this scenario, your host machine is the machine you set up earlier with the WDK and Visual Studio. The target machine is the dev board. The documentation has a link for setting up a target, and that should be enough because provisioning for the Sharks Cove is just like any other target. Here’s a short version of this process, explicitly stating what is happening on each machine.

  • Get the WDK Test Target Setup msi from the host (development) machine and bring it to the target (Sharks Cove) via USB or network if that is setup.
  • Run this on the target.
  • Once that is run, you can finish provisioning in Visual Studio on the host machine. I’d recommend reading through both the provisioning steps and setting up kernel debugging links provided in this section before doing either. That’s because
    you’ll want to select Provision computer and choose debugger settings the first time through so you don’t have to do the process twice.

Attaching a component

The documentation gives an example of the ASL entry for an ADXL345 accelerometer. This is the part that I worked with to test the board, so I’ll talk about using that part through the remainder of this post. To attach the part, I used a breadboard,
but with the proper cables, you can just connect it directly. The pin mappings can be found in this guide (SpbAccelerometer driver cookbook). Once connected, just follow the steps detailed in Step 6 from the Sharks Cove guide we’ve been following. The ASL entry I used during development looked slightly different: Device(ADXL) instead of Device(SPBA) and Name(_HID, “ADXL345”) instead of Name(_HID, “SpbAccelerometer”).  Pay attention to these fields in whatever
version of the ASL entry you see available at the time of reading this. It will be important when installing your driver.

Installing and debugging a driver

Using the sample driver linked at the bottom of the page, you can test your part. After opening the solution, be sure to set the configuration platform in Visual Studio. The instructions are on the sample’s documentation page. Be sure to set it to a
debug configuration or you may encounter signing issues. The simplest method of building and testing the driver is through Visual Studio itself.  Right click the package project and select properties. Under Driver Install > Deployment, enable deployment, set your target machine to Sharks Cove, and select Install and Verify. Click OK, and you can begin debugging by clicking Debug > Start Debugging. This should build the driver, connect to Sharks Cove, copy over the driver files, install it, and finally attach to it for debugging. If the build is successful, you should see various cmd windows popping up and closing on the Sharks Cove. After they are finished, if successful, a Debugger Immediate Window will appear in
Visual Studio already broken into upon driver load. You can then set break points, continue, break, and step through code like normal with Visual Studio.

The alternative to using Visual Studio to deploy and debug is manual deployment and debugging with WinDbg (included in the WDK). Instructions for manual deployment can be found on the sample’s documentation page. Before you install the driver with devcon, you will need to do some setup so that you can attached to the driver on load with WinDbg. First, you need to copy wdfverifier.exe from …Windows Kits8.1Toolsx86 on the host to your Sharks Cove. This tool will allow you to set WUDFHost.exe, the process that hosts the driver, to break when your driver is loaded. Run it on the Sharks Cove. Go to the Global WDF Settings tab. Where it says, “At [driver loadstart], Host Process will wait [0] seconds for user-mode debugger,” set the dropdown to driver load and the time to 10 or more seconds. You should check the kernel debugger checkbox below this if you plan on kernel debugging. When you install your driver, WUDFHost.exe will break upon you driver loading and wait as long as you specified. At this point you need to attach a debugger. For user-mode debugging, you need to run WinDbg as an administrator on the Sharks Cove. Click File > Attach to process. Find WUDFHost.exe and attach. If you have multiple WUDFHost.exe processes, use tasklist /M SpbAccelerometer.dll from the command line to get the PID of the correct WUDFHost.exe. You can now attach a remote WinDbg session to this one from your host machine if you
prefer. To do this simply run .server npipe:pipe=<pipename> in the WinDbg session on your Sharkscove where pipename is whatever you prefer. Next, start a WinDbg session on your host and click File > Connect to a Remote Session. You will need to type the output of the .server command after –remote (e.g. npipe:pipe=examplepipe,server=examplehost). Lastly, you can kernel debug through USB if it is setup. Simply start WinDbg on your host and click File > Kernel Debug. Select the COM tab and change the port to comX where X is the number you found for the target when provisioning. Once attached in all cases, you will need the symbols for your driver, the pdb file in the binary output of your Visual Studio project. You can either copy it to your Sharks Cove for local debugging or keep it in place and attach remotely to the Sharks Cove. Whichever method you choose, in WinDbg, on the host unless using the first option, select File > Symbol File Path. Add the full path to the directory containing the pdb file. If you’d like to look at or step through source code, add the full path to the directory containing the source files for the driver in File > Source File Path. Paths are separated by a semicolon. Links to debugging with WinDbg can be found in the Sharks Cove documentation.

Tips and Tricks

I wanted to close with a few things that I did to make my life easier when working with Sharks Cove. There’s nothing fancy here, just stuff that you may or may not find useful or already thought of yourself.

  • Pinning things to the taskbar can save you a bit of time. I pinned cmd as admin to the taskbar. If you don’t know how to make it launch as admin by default, pin it, right click the pinned icon, right click the program name, click properties, click Advanced, and then check Run as Administrator. I also pinned WinDbg. I also pinned File Explorer.
  • Speaking of pinning, I pinned C:DriverTest to my favorites in File Explorer. This is the folder on the target where your driver is deployed to by the WDK.
  • I adjusted the power options on the Sharks Cove to keep it from going to sleep.
  • Two options if you aren’t kernel debugging and don’t have a second keyboardmouse setup:
    • Mouse without borders: a program that allows you to use one set of mouse and keyboard over multiple devices
    • Remote desktop (also doesn’t require a second monitor)
    • In WinDbg, you can create workspaces in the File menu. I used these to save the paths to symbols and source file for my driver, so I didn’t have to do it every time.

So there it is, pretty much my knowledge and experience on the Sharks Cove. I hope this is helpful to those getting started, because I want to be able to help those who are having similar experiences as me.

Microsoft Azure Infrastructure as a Service – Part 2

Last blog post we discussed on how to create Microsoft Azure Virtual Machine using Azure infrastructure as a service . In this blog post will be focusing on Microsoft Azure Cloud Services and the Virtual Machine Availability Set. As you might know what Cloud Services from the Microsoft Azure PaaS is, in this blog post I will discuss the Cloud Service and its relation to the Virtual Machines.
If you are moving to Microsoft Azure , you will certainly be looking for high availability for your applications…(read more)