Библиотека Header2ActionBar для Android

(демо для привлечения внимания)

Вы, наверное, уже видели похожее в приложениях от Google (Play Музыка, Google Пресса) и, возможно, каких-либо других. Для этих целей уже довольно давно существует библиотека от ManuelPeinado — FadingActionBar, которая прекрасно выполняет свою задачу, но к сожалению, имеет два «фатальных» недостатка.

Второй из них описан как известная проблема:

Known Issues

There is an important issue with the library and ListViews. More specifically, things don't work quite right when the activity is re-created due to a configuration change. So, unless you handle configuration changes yourself (or your activity is portrait/landscape only), I strongly suggest you stick to having your content in a ScrollView until a solution to this issue is found.

Стараясь исправить этот недостаток, я решил написать свою реализацию, тем самым устранив и оба недостатка :)

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

Сегодня мы разберем как создавать плитки (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 ― это полностью ручная операция, которая требует внимательности и скрупулезности и занимает продолжительное время, мы автоматизировали процесс удаления задачи из релизной ветки.

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

Наверное, каждому хотелось бы иметь свой домашний сервер, который не только выполнял бы роль медиа-сервера, но и позволял использовать его как файловое хранилище, хранилище 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», где можно управлять сниппетами: