Продолжаем модернизировать приложение, которое мы создали в прошлой статье.

Сегодня мы разберем как создавать плитки (Tile) для Windows 8.1 приложений и каким образом можно реализовать динамическое изменение контента на них.

Наверное, как и многие разработчики под Android, столкнулся на днях с необходимостью реализовать в своем приложении выбор файла пользователем. Так как изначально в Android такого функционала нет, обратился к великому и ужасному. Это показалось мне странным, но из вороха вопросов на stackoverflow и небольшого числа отечественных форумов можно выделить всего три основных источника:

1. Android File Dialog – почти все ссылки из stackoverflow ведут сюда. В принципе, неплохое решение, но реализовано через отдельную activity, а хотелось чего-то в духе OpenFileDialog’а из .Net.
2. В данной статье речь идет вообще об отдельном файл-менеджере, и почерпнуть какие-то идеи из неё не удалось.
3. Идея же отсюда очень понравилась, однако, как мне показалось реализовать все это можно несколько красивее.

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

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

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

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

Статья не претендует на подробный анализ потенциальных проблем, это просто рассказ из жизни одно реального Android приложения.

JavaScript занимательный язык программирования.

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

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

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

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

Попытайтесь повторить это сами

Как правило, настроенный должным образом сервер Nginx на Linux, может обрабатывать 500,000 — 600,000 запросов в секунду. Но этот показатель можно весьма ощутимо увеличить. Хотел бы обратить внимание на тот факт, что настройки описанные ниже, применялись в тестовой среде и, возможно, для ваших боевых серверов они не подойдут.

Минутка банальности.

yum -y install nginx

На всякий пожарный, создадим бэкап исходного конфига.

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.orig
vim /etc/nginx/nginx.conf

А теперь можно и похимичить!

В 2009 году я рассказывал, как мы строим наш маленький семейный бизнес с оборотом 1500 долларов в месяц. Прошло четыре года. Бизнес вырос до оборота 500 000 долларов в год, и мы его потеряли. Самое время рассказать о допущенных ошибках.

Что же произошло?

Публикация на хабре позволила нам познакомиться с разными людьми, наш бизнес многим понравился. Так в 2010 году мы продали 50% компании частным инвесторам. После успешной трехлетней совместной жизни в сентябре 2013 года наши партнеры отжали бизнес. Мы остались ни с чем.

Как говорил Франклин, “Опыт — это чудесное умение распознавать ошибку, которую ты допускаешь снова”. Возможно, для кого-то все, написанное ниже, знакомо и понятно. Для нас это было впервые и, оглядываясь назад, я вижу множество ошибок, которые привели к такой ситуации. Буду рад ими поделиться с вами.

Когда PVS-Studio сообщили о том, что они наконец-то выпустили standalone версию, не требующую для своей работы Visual Studio, я, конечно же, не мог пройти мимо :) До этого я уже игрался с пробной версией на коде одного из старых проектов. Сейчас же появилась возможность посмотреть на код нашего последнего проекта, собирающегося в среде разработки AVR Studio (которая eclipse-based).

Для работы требуются файлы сразу после препроцессора. Среда AVR Studio это умеет, с одним маленьким исключением — после включения флага «Только препроцессор» на выходе действительно появляются файлы после препроцессора — но по-прежнему с расширением.о вместо ожидаемого .i. Ну что ж, 5-минутный скрипт на Питоне решает это недоразумение, и анализатор отлично запускается!

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

В паре мест обнаруживаются реальные опечатки и ошибки копи-паст. Например, переменная типа одного enum-a сравнивается со значением из другого enum-a. Или же одной переменной присваивается два разных значения подряд (хотя, как указано выше, в большинстве случаев это было ложным срабатыванием для записей последовательности в регистр).

Но самой интересной, из-за чего я и пишу этот пост, была одна-единственная строчка «Possible NULL pointer dereferencing»…

От переводчика. Судя по своему опыту, а также по опыту знакомых коллег-программистов, могу сказать, что для начинающего разработчика среди всех базовых функций языка C# и платформы .NET делегаты и события являются одними из наиболее сложных. Возможно, это из-за того, что необходимость делегатов и событий на первый взгляд кажется неочевидной, или же из-за некоторой путаницы в терминах. Поэтому я решил перевести статью Джона Скита, рассказывающую о делегатах и событиях на самом базовом уровне, «на пальцах». Она идеальна для тех, кто знаком с C#/.NET, однако испытывает затруднение в понимании делегатов и событий.

Представленный здесь перевод является вольным. Однако если под «вольным», как правило, понимают сокращённый перевод, с упущениями, упрощениями и пересказами, то здесь всё наоборот. Данный перевод является немного расширенной, уточнённой и обновлённой версией оригинала. Я выражаю огромную благодарность Сергею Теплякову aka SergeyT, который внёс неоценимый вклад в перевод и оформление данной статьи.

Люди часто испытывают затруднения в понимании различий между событиями и делегатами. И C# ещё больше запутывает ситуацию, так как позволяет объявлять field-like события, которые автоматически преобразуются в переменную делегата с таким же самым именем. Эта статья призвана прояснить данный вопрос. Ещё одним моментом является путаница с термином «делегат», который имеет несколько значений. Иногда его используют для обозначения типа делегата (delegate type), а иногда — для обозначения экземпляра делегата (delegate instance). Чтобы избежать путаницы, я буду явно использовать эти термины — тип делегата и экземпляр делегата, а когда буду использовать слово «делегат» — значит, я говорю о них в самом широком смысле.

Некоторое время назад уже был опубликован аналогичный пост, с тех пор количество дополнений для Visual Studio 2010,2012 и 2013 перешагнуло планку в 4к, появилось немало новых дополнений. Ниже перечислено 20 наиболее популярных или интересных расширений для Visual Studio 2012 и 2013 в дополнение к предыдущему посту.

На хабре уже есть несколько статей о создании расширений для хрома, поделюсь своим опытом, затронув основные вещи и места, в которых у меня возникли трудности.
Что понадобится для создания расширения в двух словах:
1) Базовые знания Javascript
2) Базовые знания HTML
3) 5$

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

Вместо введения

День добрый.
Сегодня я попытаюсь рассказать о своей попытке построить систему удаленного управления ПК в пределах одного помещения.

Сразу отмечу для тех кто скажет велосипед. Да это велосипед. И мне было интересно его построить. По ряду причин. Одна из которых желание сделать своими руками а не купить.

Вступительное слово

Считается, что «киллер фичей» СКВ Git является легковесное ветвление. Я ощутил это преимущество в полной мере, ведь я перешел на Git с SVN, где ветвление было достаточно дорогим процессом: для создания ветки нужно было скопировать весь рабочий каталог. В Git все проще: создание ветки подразумевает лишь создание нового указателя на определенный коммит в папке .git/refs/heads, который является файлом с 40 байтами текста, хешем коммита.

Основными командами пользовательского уровня для ветвления в Git являются git-branch, git-checkout, git-rebase, git-log и, конечно же, git-merge. Для себя я считаю git-merge зоной наибольшей ответственности, точкой огромной магической энергии и больших возможностей. Но это достаточно сложная команда, и даже достаточно длительный опыт работы с Git порой бывает недостаточным для освоение всех ее тонкостей и умения применить ее наиболее эффективно в какой-либо нестандартной ситуации.

Попробуем же разобраться в тонкостях git-merge и приручить эту великую магию.

Здесь я хочу рассмотреть только случай благополучного слияния, под которым я понимаю слияние без конфликтов. Обработка и разрешение конфликтов — отдельная интересная тема, достойная отдельной статьи. Я очень рекомендую так же ознакомиться со статьей Внутреннее устройство Git: хранение данных и merge, содержащей много важной информации, на которую я опираюсь.

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


Первая партия йогурта меня слегка разочаровала, он был очень густой, в нем буквально стояла ложка и слишком кислый, в общем – ничего и близко похожего на вкусные йогурты из магазина. Заподозрив, что чрезмерная кислота йогурта возникла из-за слишком высокой температуры (попросту говоря – закваска «перебродила»), я замерил температуру внутри нагревательного корпуса, во время приготовления йогурта, и получил — 46°С. В инструкции по приготовлению закваски для йогурта указано, что оптимальный режим готовки — 38-42°С.

Решив разобраться с температурными режимами, я полез внутрь йогуртницы…

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

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

Мы рассмотрим здесь только Watermark'и предназначение которых – ни при каких условиях не быть удалёнными, чтобы создатель приложения имел возможность считать их после любых атак потенциального злоумышленника, а пользователи приложения о них не догадывались. Есть и другие виды вотермарок, предназначенные, например, для отслеживания изменений в приложении, эдакие скрытые чексуммы, и они также должны быть сложно удаляемы, но это уже другая история.

Самый лучший Watermark

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

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

• действия выполняются вручную, что требует сосредоточенности и аккуратности;
• жёсткие временные рамки.

В нашем случае налицо лимит по времени: релизы формируются, тестируются и выкатываются на продакшн-сервер два раза в день. При ограниченных сроках в жизненном цикле релиза процесс удаления (отката) из релизной ветки задачи, содержащей ошибку, имеет важное значение. Для её выполнения мы используем git rebase. Так как git rebase ― это полностью ручная операция, которая требует внимательности и скрупулезности и занимает продолжительное время, мы автоматизировали процесс удаления задачи из релизной ветки.

Автор изображения MVBen

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

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

Приветствую!

Наверное, каждому хотелось бы иметь свой домашний сервер, который не только выполнял бы роль медиа-сервера, но и позволял использовать его как файловое хранилище, хранилище Backup’ов и принт-сервер.

В один из чудесных осенних дней меня тоже посетила эта мысль. Дело в том, в доме «развелось» слишком много устройств, которые захотелось объединить во что-то структурированное. Было принято решение поднять домашний сервер. В качестве ОС сначала хотелось использовать Windows Server 2012 Essentials, в состав которого вошли такие продукты, как Windows Home Server и Windows Small Business Server, но после нескольких часов работы с ней я понял, что использовать Windows Server 2012 в домашних условиях слишком «жирно». Тогда я решил использовать ОС попроще, а именно Windows 8 Pro, лицензия на которую лежала без дела.

Предупреждение. Я прекрасно понимаю, что поднять домашний сервер на Unix-подобных ОС, возможно, было бы и проще, но в данном материале я хочу рассказать, как поднять такой сервер на клиентской ОС Windows 8 Профессиональная обычному пользователю ПК (ну, или почти обычному), который никогда не имел опыта общения с Unix.

«Если у вас паранойя, это ещё не значит, что за вами не следят» © Народная мудрость

Прочитав пост Как я внедрял первое правило ведения бизнеса в России, у меня возник вот такой вопрос:

Что делать если компания разрабатывает программный продукт (SaaS), и в процессе разработки необходимо использовать локальные develop и stage сервера? Что будет если “злоумышленник” получит физический доступ к дискам и как не отдать ему все исходные коды проектов? А если мы раскатываем код на боевую через скрипты, Chef или Puppet, то отдаём ещё и все доступы к боевым площадкам.

Ответ очевиден: шифрование всего ценного. Но как мы все знаем, вариантов шифрования масса. Начиная от шифрования отдельных файлов и создания криптоконтейнеров (например TrueCrypt) и заканчивая полным шифрованием дисков.

Вы можете сказать «так ты же сам нарушаешь правило и держишь свои локальные сервера в офисе?». И я соглашусь, но с оговоркой. Для комфортной разработки, чем ближе исходники, тем лучше, а учитывая скорость интернета для юридических лиц в регионах, которую можно получить за разумные деньги, держать develop и stage сервера где-то далеко приведёт к мучительной боли. Здесь я говорю про схему, при которой на машинах разработчиков нет исходных кодов. Весь код лежит на сетевой шаре develop сервера. Да и в целом пинг наружу и пинг в локальном гигабите немножечко разные вещи.

Итак, приступим к шифрованию.

Возможности встроенного в браузер инструмента Chrome Developer Tools можно расширить с помощью сниппетов. Это ускоряет разработку и упрощает рабочий процесс. Хорошая коллекция сниппетов есть на GitHub'е.

Сниппеты в Google Chrome

Подробно о функциях сниппетов можно почитать в официальной документации Chrome. А вот краткая инструкция:

1. Зайти в «chrome://flags» — Отметить «Enable Developer Tools experiments».
2. Открыть DevTools: «Settings» — «Developer Tools Experiments» — Отметить «Snippets support».
3. После перезагрузки во вкладке DevTools «Sources» появится «Snippets», где можно управлять сниппетами: