Привет, хабрасообщество!

Наконец-то свершилось то, чего я так ждал! Мы долго трудились, и вот результат! Пожалуй, что имеет смысл сообщить просто факт: мы рады представить обновленный центр по виртуализации на Microsoft TechNet.

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

1. Преимущества виртуализации

2. Виртуализация серверов

3. Виртуализация локальных настольных компьютеров

4. Виртуализация удаленных рабочих столов

В корпоративном секторе иногда возникает задача автоматической конвертации документов из одного формата в другой, а так же задача их програмной обработки и модификации. Казалось бы, в чём проблема: для нормальных форматов давным-давно написаны полнофункциональные библиотеки для работы — так что Perl или Python в руки и вперёд.

Но, к превеликому сожалению для всех системных администраторов и программистов различных бизнес-приложений, огромная масса документооборота в данный момент всё ещё осуществляется с использованием закрытых и плохо поддающихся модификации и разбору форматов. Что уж тут лукавить — речь идёт о doc, xls и иже с ними, а так же во многом о docx, xlsx и подобных. Что делать с такими файлами, особенно если у вас нету свободной Windows с установленной последней версией Office, — совершенно непонятно. Безусловно, если у вас есть Windows, Visual Studio и навыки работы в C#, то проблем с анализом документов Microsoft будет значительно меньше. Зато возникнут проблемы с ODF. Плюс часто хочется сохранять результат в формате PDF, дабы уже никто не мог его изменить.

К счастью, есть достаточно универсальный способ работы практически с любыми распространёнными форматами документов на любой платформе. О нём и пойдёт речь дальше.

Знакомо ли вам такое состояние, когда вы настолько увлечены идеей, что полностью погружаетесь в процесс ее реализации, забывая о времени и окружающем мире? А завершив, испытываете радость и даже счастье? Значит, у вас есть опыт потоковых состояний – особых ресурсных состояний сознания, когда все внимание сфокусировано на цели, и в результате замечательные идеи рождаются сами собой, и время концентрируется, вмещая гораздо больше, чем в обычном состоянии.
Тема эффективности потоковых состояний для работы и творчества уже несколько раз поднималась на Хабре, и в этой статье мы хотим обсудить практическую часть – что необходимо для того, чтобы вызывать это состояние «на заказ»?

RoboGuice — это библиотека, которая позволяет пользоваться всеми преимуществами Contexts and Dependency Injection при разработке приложений на Андроиде.
Как несложно догадаться, RoboGuice основан на Google Guice.
Сразу оговорюсь, что в качестве перевода слова «injection» я буду использовать слово «инъекция».

Зачем колоться?

Думаю, что у многих читателей сразу возникнет вопрос: «Зачем эти сложности с CDI на мобильной платформе? Наверняка это всё занимает много места и медленно работает.»
Попробую убедить таких читателей в обратном, а именно в том, что CDI на мобильной платформе очень даже жизнеспособен и существенно облегчает жизнь разработчикам.

Небольшой отчет o конференции AgileDays Екатеринбург ‘2010, я уже публиковал. Теперь ScrumTrek выложили слайды презентаций и видео докладов.

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

Кому и зачем это нужно?

Это не нужно тем, кто мало времени проводит за компьютером. Остальным, на мой взгляд, просто необходимо.

Когда речь идет о преимуществах печати вслепую, обычно говорят о высокой скорости набора. Печатать быстро — значит экономить время, которого порой так не хватает. Плюсы скоростной печати достаточно очевидны, однако не для всех они имеют критическую значимость. Некоторые могут вполне резонно сказать: «Мне не нужно печатать быстро, потому что у меня нет необходимости набирать большие тексты, а для переписки и прочих бытовых нужд вполне достаточно смотреть на кнопки и нажимать их одним пальцем» — и будут по-своему правы, ведь им так удобно. Но дело не только в скорости как таковой — есть два очень важных момента, касающихся здоровья, которые почему-то остаются без внимания.

В одном из предыдущих своих постов я пообещал продолжить тему о теории DISC для «нечайников». Сегодня очередной пост в эту сторону.
Наверное одним из ключевых моментов работы программиста, прожект-менеджера, да и вообще любого человека, как связанного с IT так и не связанного – это привычка, навык или умение доводить до конца начатые дела.
В этом посте мы разберёмся с этим вопросом.

От переводчика: данный перевод продолжает цикл публикаций по управлению Open Source проектами, начатый здесь.

Модель управления описывает роли, которые могут занимать участники проекта, а также процесс принятия решений внутри проекта. Кроме того, она описывает основы правил участия в проекте и процесс общения и обмена информацией между членами команды проекта и сообществом. Другими словами, именно модель управления предохраняет проект от скатывания в хаос. Этот документ объясняет, почему необходима модель управления, даёт некоторые рекомендации по решению проблем, возникающих при принятии проектом модели управления и описывает ключевые области, которые должны быть в модели. Также здесь вы найдёте описание процесса включения вашей модели управления в управляющую документацию.

Преамбула

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

И вот, вы, принимая пост, знакомитесь с командой: вроде бы есть потенциально сильные разработчики с опытом, есть несколько подающих надежды юниоров. Но что-то сразу бросается в глаза. И чем дольше вы вглядываетесь в эти занятые работой умные лица, тем более понимаете, что перед вами не команда, а «группа разработчиков». А то, что они пишут… Вы и не думали, что программисты могут так писать код. Вы смотрите на пластилиновую архитектуру, на классы в 6000 строк кода, на методы, занимающие десять страниц машинописного текста, на кейсы, ветвящиеся как головы Лернейской гидры. И у вас появляется невольный вопрос: а можно ли что-то с такой командой сделать вообще?

И мой ответ — можно. И нужно!

Так уж вышло, что в прошлом году волею судеб я влился в государственную структуру. И сразу же получил задание установить электронные цифровые подписи в управлении муниципального заказа для участия в электронных торгах. До этого с ЭЦП в практическом применении я никогда ранее не сталкивался. А совсем недавно, с 1 января заработал портал zakupki.gov.ru, через который должны проходить все государственные закупки.



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

На примере реальной ситуации рассмотрим все этапы установки ЭЦП и настройки рабочего места. Надеюсь, мой материал поможет тем, кто только начинает работу с ЭЦП, и в частности с электронными закупками.

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

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

Большинство провальных проектов обладают одной закономерностью. Они абсолютно лишены структуры. Я называю архитектуру таких систем «пластилиновой».

Не так давно мы размещали подкаст, в котором Антон Шаяхов поведал миру, как быстро и качественно зарегистрировать ИП. Совершенно незаслуженно мы обошли вниманием более сложный процесс. Исправляемся.

Дано: ведется деятельность в качестве ИП, есть доступ в интернет, уровень интеллекта выше среднего.
Задача: в кратчайшие сроки и с минимальными затратами закрыть ИП и зарегистрировать ООО.

Зачем писать тесты? Когда их писать? Когда их не писать? Хабр был и остается неравнодушен к этим и другим вечным вопросам, и не один хабровчанин провел бессонную ночь, придумывая убедительные на них ответы (чтобы оппоненты, наконец, заткнулись).

Я решил взять противника не умением, а числом, и поэтому вот вам 19 причин, по которым писать тесты все-таки стоит (в хронологическом порядке). Итак, тесты

Ларс Вогель — евангелист Eclipse.
Под катом Вы обнаружите перевод его статьи, которая описывает процесс создания Android-приложений с помощью Eclipse. Используется Eclipse 3.6, Java 1.6 и Android 2.3 (Gingerbread).
Часть 2

В то время, как переводы GPL версии 2.0, 3.0 и LGPL распространены широко, другие популярные свободные лицензии на русском встречаются редко. Я перевела Apache License 2.0 и Eclipse Public License на русский язык. Жду замечаний по качеству перевода.

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

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

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

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

Android содержит массу способов для организации данного подхода, но одним из самых удобных можно признать использование AsyncTask и ProgressDialog.

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

Совсем недавно я написал пост, в котором выражал свое желание перейти от разработки для Windows Phone 7 к программированию под Android. К сожалению, некие внешние обстоятельства затормозили этот процесс и изучение идет не такими быстрыми темпами как хотелось бы. Но тем не менее желания не убавилось и скоро смогу уделить больше времени для Android.
А сегодня хочу рассказать о такой заурядной вещи, как обработка щелчка кнопки. Статья предназначена для новичков и будет говорить об очевидных вещах, но мне она стоила одной ночи.

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

Статья затронет весь цикл разработки приложения. Вместе мы напишем простенькую игру “Крестики-Нолики” с одним экраном (в ОС Android это называется Activity).

Отсутствие опыта разработки на языке Java не должно стать препятствием в освоении Android. Так, в примерах не будут использоваться специфичные для Java конструкции (или они будет минимизированы на столько, на сколько это возможно). Если Вы пишете, например, на PHP и знакомы с основополагающими принципами в разработке ПО, эта статья будет вам наиболее полезна. В свою очередь так как, я не являюсь экспертом по разработке на Java, можно предположить, что исходный код не претендует на лейбл “лучшие практики разработки на Java”.

Как ни странно, но на русском почти нет нормальных статей по виджетам для Android. Да и на англо язычных ресурсах почти нет простых примеров для старта, все примеры почему-то сложные и тяжелые для понимания. Спешу это исправить.