Кто, если не ты? Когда, если не сейчас?



В предыдущей части мы научились запускать PowerShell, разобрались с политикой выполнения сценариев. Поняли, что такое командлеты, знаем, как передавать их по конвейеру и как получить их свойства. Узнали, что PowerShell имеет огромный Help.

В этой части мы разберёмся с переменными, узнаем, что они за типы и как к ним обращаться, как их сравнивать и выводить всевозможными способами. Обязательно разберёмся с циклами и напишем несколько функций.

6 го мая 2014 года Scaled Agile, Inc. был назван финалистом 2014-го года в номинации Red Herring Top 100 в США. Эта новость стала вполне ожидаемой для специалистов в Enterprise Agility и для консалтинговых фирм, предоставляющих услуги в организационной трансформации компаний. Причина в этом проста — потребности рынка серьезно изменились.

Ряд глобальных компаний, таких, как ING, TomTom, T-Mobile и IBM уже давно проявляют интерес к SAFe. Швейцарские компании такие как Swisscom, SwissPost, Kuoni и Credit Suisse также успешно внедряют SAFe силами собственных сертифицированных и внешних консультантов.

Александр Александров — «дедушка тестирования» в СНГ делал доклад на юбилейной 15-ой SQA Days в Москве.

Слайды:
www.slideshare.net/VLDCORP/ss-33747358

Видео выступления:

Примечание переводчика: Перевод первой статьи из блога «A Year of Productivity» был благосклонно встречен хабра-сообществом, и меня попросили перевести еще несколько статей из этого блога. Приведенная ниже статья — самая большая и самая близкая к практике, её перевод затянулся у меня на несколько месяцев. Как и прошлый раз рекомендую читать комфортными порциями, записывая (или копируя куда-нибудь) советы, которые хочется попробовать применить на практике.

«Хаки» времени

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

Управление временем – хороший источник вашей продуктивности, но все три ингредиента абсолютно важны, если вы хотите быть более продуктивными на ежедневной основе. Именно поэтому в статье вы найдете набор приемов из всех трех областей.

Для начала вот несколько моих любимых приемов по тому как:
-  получить больше времени;
-  тратить время на правильные вещи.

Приводим доклад khroliz Игоря Хрола, компания Wargaming, Минск, с конференции SQA Days 15.

Видео доклада:
vimeo.com/93944414

Презентация:
www.slideshare.net/slideshow/embed_code/33725306#

Я 8 лет работаю в этой отрасли, и я считаю, что у нас есть проблемы )

Прежде всего, тестирование считается неинтересной профессией. Что из этого следует? В отрасль приходят неопытные люди, либо недостаточно квалифицированные. Сложную работу, т.к. люди неопытные, некому делать. И получается, что мы делаем несложную работу. А т.к. мы делаем несложную работу, то нам мало платят, т.к. бизнесу мы приносим не так много, как хотели бы. И круг замыкается.

Доброго времени суток, многоуважаемый %USERNAME%. Меня зовут Голованов Сергей, и я всё еще являюсь ведущим вирусным аналитиком в «Лаборатории Касперского». Я понимаю, что название этого поста в корпоративном блоге компании может вызвать смех, грусть, а у некоторых даже эпилептический припадок, но дайте мне всё объяснить.

Я понимаю, что для всех батники выглядят как нечто очень простое и со времен AUTOEXEC.BAT уже практически забытое, в то же время эксплойты, если вы конечно не профессиональный исследователь уязвимостей, выглядят очень сложно и практически неправдоподобно, особенно для некоторых разработчиков. Но! В данном посте я постараюсь перевернуть эти представления и рассказать, что всё как будто наоборот. Батники чуть легче и сильнее по функционалу brainfuck'а, а эксплойты не страшнее сортировки пузырьком на basic'е.


(Осторожно! 3 МБ иллюстрированного потока сознания и куча скриптов)

Всем привет. Сегодня я хотел бы затронуть тему машинного перевода. Получив работу в небольшой IT-компании сразу же после окончания университета, я заметил, что многие начинающие IT-специалисты, плохо владевшие английским языком, часто использовали в работе различные веб-сервисы: Яндекс.Перевод, Переводчик Google и др. Не буду спорить, что возможно эти сервисы частично полезны для общего понимания текста, однако неопытным пользователям получить адекватный перевод используя их очень сложно. Иногда такие переводы вызывают просто «хохму». Помнится, как однажды один новичок в простом предложении «I have a wife and two young children» получил следующий перевод: «Я имею жену и двух малолетних детей». Кстати, перевод его совсем не смутил.

5-го сентября 1977 года автоматический зонд Voyager 1 был запущен с мыса Канаверал (Флорида, США). 22 февраля 2014 года Voyager 1 удалился от Солнца на расстояние 19 000 000 000 км. На момент публикации поста зонд находится на расстоянии 19'010'023'115 км от Земли, и 19'037'197'698 км от Солнца.

А вот его 36-летний путь в виде инфографики:

У нас — десктоп. Мы сидим работаем — код пишем или котиков смотрим, а этот ящик ревет рядом. У нас есть кусачки, паяльник, синяя изолента, немного проводов, чуть термоусадочного кембрика и начальные знания в электротехнике и устройстве компьютера. Можно ли как-то поковырять этот ящик, чтобы он хоть чуть тише ревел?

Как известно, при использовании интерфейса IEnumerable<> там, где подразумевается коллекция, могут случаться проблемы (см. например Проблемы использования IEnumerable и LINQ против LSP). К счастью, в .NET v4.5 в 2012-м году (немного поздновато, но лучше поздно, чем никогда), появились интерфейсы IReadOnlyCollection<>, IReadOnlyList<>, IReadOnlyDictionary<> (далее буду их обобщённо называть IReadOnly-интерфейсы). В отличие от IEnumerable<>, IReadOnly-интерфейсы дают возможность достаточно и без лишних требований обозначать функциональность коллекции, что и позволяет их рекомендовать для использования вместо IEnumerable<> везде, где подразумевается чтение коллекции. Но тут встречается одно затруднение. Одним из важных компонентов, потребляющим и создающим коллекции, является LINQ и, особенно, его часть «LINQ к объектам». К сожалению, IReadOnly-интерфейсы появились через 5 лет после LINQ, и в нём не используются. Все входные и выходные коллекции LINQ-операций имеют базовый тип IEnumerable<>, исходя из ограниченных возможностей которого, многие операции подразумевают лишние затраты: полный последовательный перебор или даже создание промежуточных копий входных коллекций. Более того, возвращая из операций тот же IEnumerable<>, LINQ требует при дальнейшем использовании результата опять использовать полный перебор и создание промежуточных копий. В связи с этим, у меня давно зрела мысль «подружить» LINQ с IReadOnly-интерфейсами.

Привет! Меня зовут Сергей Константинов, в Яндексе я руковожу разработкой API Карт. Недавно я поделился опытом поддержки обратной совместимости со своими коллегами. Мой доклад состоял из двух неравных частей. Первая, большая, посвящена тому, как правильно разрабатывать API, чтобы потом не было мучительно больно. Вторая же про то, что делать, если вам нужно что-то рефакторить и не сломать по дороге обратную совместимость.



Если заглянуть в Википедию, то про обратную совместимость там будет написано, что это сохранение интерфейса системы при выпуске новых версий. На самом деле, для конечных пользователей обратная совместимость означает, что код, написанный для предыдущей версии системы, работает функционально так же и в следующей версии.

Для разработчика обратная совместимость в первую очередь подразумевает, что единожды принятое обязательство предоставлять какую-либо функциональность невозможно отменить, исправить или перестать поддерживать.

Это перевод статьи Рафаля Лукавецки из компании Project Botticelli Ltd, которая предлагает онлайн-обучение и курсы по разным технологиям, в том числе машинному обучению и Power BI и так далее. Оригинал статьи можно найти по адресу

Сервис машинного обучения Azure Machine Learning в настоящее время находится в предварительном публичном тестировании доступном каждому, у кого есть учетная запись Azure (или хотя бы триальный доступ). Если вам интересно почему я всегда был настолько возбужден этой технологией, посмотрите мою обзорную статью, написанную месяц назад или читайте дальше этот пост, в котором я обо всем расскажу.



Если кратко, для того чтобы выполнять задачи аналитики с прогнозированием (predictive analytic) с помощью Azure Machine Learning вам достаточно выполнить следующие шаги:

Вчера на Хабре в комментариях к статье про утечку базы паролей Яндекса появилась информация о том, что в сеть попала база паролей от почтовых ящиков Mail.Ru. Мы проанализировали все аккаунты, оказавшиеся в этой базе, и хотим рассказать о том, что это было и какие мы приняли меры.

Что произошло? Откуда база?

Массового взлома, имеющего под собой какую-то конкретную причину или дыру в безопасности, не произошло. Анализ базы показал, что, скорее всего, она собиралась по частям из нескольких баз паролей, которые были украдены у пользователей в разное время и разными способами, в том числе при помощи вирусов, фишинга и т.п.

Как вам вероятно известно, с 5 по 10 сентября в Берлине будет проходить крупнейшая выставка потребительской электроники IFA 2014. Однако время анонсов уже наступило.



В рамках специального мероприятия Microsoft, проходившего под лозунгом «Ready for #morelumia?», мы представили три смартфона из новой линейки: тонкий Lumia 830 и два «селфифона» Lumia 730 DS и Lumia 735.

На этой неделе интернет был потрясен историей, связанной с утечкой сотен интимных фотографий знаменитостей (статьи на Хабре на связанную с этим тему здесь и здесь). Одно из самых тщательных расследований этой истории провел рожденный в Австралии предприниматель, блогер, инженер и разработчик софта (все это в одном лице) Ник Кубрилович (Nic Cubrilovic). Ник известен тем, что в разные периоды своей карьеры был журналистом и консультантом Techcrunch и Crunchpad, редактором TechcrunchIT, основателем или со-основателем Omnidrive, Solutionstap, MyVirtualDrive, Webwall, 2web и прочее. Подробности – под катом.

Многим разработчикам и тестеровщикам, использующим Visual Studio, известен Брайан Келлер (http://blogs.msdn.com/b/briankel/ ) с его регулярно обновляемой виртуальной машиной, которая содержит последнюю версию Visual Studio и всю необходимую инфраструктуру для изучения и оценки всех возможностей средств разработки. Эта виртуальная машина сопровождается набором лабораторных работ aka.ms/VS13ALMVM, которые уже помогают оценить возможности средств разработки или даже научиться использовать новые возможности о которых вы либо не знали, либо не пользовались раньше.

Лабораторные работы — на английском языке, и каждый раз, когда мы рассказывали об этом наборе лабораторных и виртуальной машине, нас просили сделать эти лабораторные работы доступными на русском языке.

Сегодня мы рады сообщить, что благодаря ahriman, мы запустили проект по локализации этих лабораторных работ. Встречайте — первый набор из 4-х локализованых лабораторных работ, которые покрывают тему управления тестированием в Visual Studio 2013!

Повсеместно принято, что в «серьезных» CRUD приложениях база данных становится во главу угла. Ее проектируют самой первой, она обрастает хранимыми процедурами (stored procedures), с ней приходиться возиться больше всего. Но это не единственный путь! Для Entity Framework есть Code First подход, где главным становится код, а не база. Преимущества:

• Никакого генерированного кода
• База — это снова просто хранилище. Над ней не надо дрожать, дропается легко и без проблем.
• Простейшая установка среды разработки. Выкачал код и запустил — никакой возни с бэкапами.

Есть и пара недостатков, но они скорее связаны с Entity Framework, а не с Code First подходом как таковым; о них чуть позже.

Ниже я покажу на примере, насколько просто разрабатывать с Code First подходом.

Жили-были в двух соседних деревушках Вилларибо и Виллабаджо две команды разработчиков. И те и другие делали ревью кода, писали тесты, приводили рефакторинг, но через год разработки в Вилларибо уже выпустили релиз и вышли в продакшн, а в Виллабаджо все еще проводят рефакторинг и чинят баги. В чем же дело?

Разработка ПО – область, подверженная рискам. В нашей сфере при наступлении одного или нескольких рисков, срок поставки рабочей версии может сдвинуться не на привычные и комфортные 10-20%, а на все 150-300%. И надо признаться, что это далеко не предел.

Мы можем либо скрестить пальцы и надеяться, что удача будет сопутствовать проекту во всем, либо признать, что по статистике большая часть проектов по разработке ПО «проваливается» и предпринять дополнительные усилия по ослаблению возможных рисков.
Моя практика показывает, что клиенты крайне неохотно работают по схеме T&M и чаще предпочитают Fixed Price. В условиях зафиксированной стоимости наступление рискового случая означает автоматическое снижение рентабельности проекта: сотрудники получают зарплату ежемесячно, а не за сданные проекты.

До Agile и XP вся ответственность за работу с рисками ложилась на менеджеров. В гибких методологиях разработчики гораздо больше вовлечены в процесс и делят ответственность с менеджерами. Однако, принципы XP и Agile – больше методологические, чем технологические. Я думаю, что с рисками эффективнее работать комплексно на всех уровнях, в том числе на самом низком уровне, т.е. во время проектирования и написания кода.

Почему об этом следует думать разработчику, если есть менеджер?

1. Не секрет, что если факап случится, менеджмент примет единственное «супер-умное» решение: «давайте поработаем сверхурочно и в выходные»
2. Премии сотрудники получают тоже обычно за в срок сданные, а не за проваленные проекты
3. Чувство сделанного дела, в конце концов. Гораздо приятнее сдать проект во время и видеть улыбку клиента, чем с опозданием в полгода отвязаться от «трудного ребенка»

С моей точки зрения спокойная рабочая обстановка вместо авралов и бонусы – неплохая мотивация, чтобы начать заботиться об этом.

Один из главных отвлекающих факторов, мешающих сосредоточиться — шум. Однако не любой шум мешает работать — очень многие гораздо легче погружаются в «поток» под музыку или в шумном кафе. Существуют даже научные исследования, подтверждающие положительное влияние умеренного шума на решение творческих и интеллектуальных задач.

Сайт Noisli содержит коллекцию фоновых шумов на любой вкус и возможность смешивать их в произвольной пропорции. Здесь есть и звуки природы — шум дождя, плеск воды, пение птиц, шуршание листьев, и звуки техногенного характера — стук колёс поезда, звук работающего вентилятора, и звуки многолюдного кафе. Есть и искусственные белый, розовый и коричневый шум. Коллекция звуков постоянно пополняется.

От переводчика:
Немало копий сломано в спорах о том, когда уместнее KISS, а когда DRY, когда лучше как можно быстрее и проще решить задачу любыми средствами, а когда стоит создавать красивые и универсальные абстракции. Натан Марц, автор популярного фреймворка Storm, используемого в Твиттере, предлагает свой вариант. Чтобы не создавать тонны бесполезного кода ради абстрактной универсальности и в то же время не позволять системе превращаться в кашу из костылей, он использует «разработку через страдание» (suffering oriented programming).

---

Однажды меня спросили: «Как ты решился пойти на такой страшный риск — писать Storm одновременно с запуском стартапа?» (Storm — фреймворк для распределённых вычислений в реальном времени). Да, пожалуй, со стороны создание такого крупного проекта для стартапа кажется крайне рискованным. Тем не менее, с моей точки зрения это вообще не было рискованным делом. Трудным, но не рискованным.

Я использую стиль разработки, который сильно уменьшает степень риска таких больших проектов, как Storm. Я называю этот стиль «разработкой через страдание». В двух словах: не занимайтесь реализацией технологий, от отсутствия которых вы не испытываете страданий. Этот совет применим как к большим, архитектурным решениям, так и к маленьким повседневным задачам. Разработка через страдание существенно уменьшает риск, гарантируя, что вы всегда работаете над чем-то важным, и что вы хорошо разобрались в предметной области, прежде чем вложить в решение много сил.

Я придумал такую мантру разработки: «Сначала сделай, чтобы было. Затем — чтобы было красиво. Затем — чтобы было быстро».