Дайте-ка угадаю: вы согласны с тем, что писать тесты — это хорошо. Это повышает надежность системы, ускоряет разработку, проект с хорошим тестовым покрытием поддерживать легко и приятно, а TDD — это вообще почти идеал процесса разработки. Но не у вас в проекте. То есть, оно клёво, но, к сожалению, сейчас столько работы — просто завал. Куча задач, одних только критических багов — два десятка, плюс надо срочно дописать этот модуль и еще написать письмо заказчику… Так что тесты, наверное, будем прикручивать уже в конце, если время останется. Или в следующем проекте. Нет, ну там точно полегче будет. Скорее всего.

Как, узнали ситуацию?

Так вот — чушь всё это. Сфера ИТ — бесконечна, как вселенная, куча работы будет всегда. Можно или начать писать тесты прямо сейчас, или не сделать этого никогда. Я тут набросал короткий план, как начать это делать за 10 шагов, по шагу в день, по 10 минут на шаг. И когда я говорю «10 минут» я имею в виду не «3 с половиной часа» и не «ну сколько-то времени, лучше побольше», а именно 600 секунд. Если у вас нету в день 600 секунд свободного времени — срочно меняйте проект, работу, профессию, страну проживания (нужное подчеркнуть), потому что это не жизнь, а каторга какая-то. Поехали.

Наша компания занимается разработкой web-приложений на заказ. Не сайтов-визиток, а именно приложений. Чаще всего — для внутрикорпоративного использования.

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

На сайте немало постов о том, какие условия нужно включать в договор на создание сайтов и программ (краткий список ниже), но нет договора в формате, который можно взять за основу для составления своего договора. Мы изучили условия из постов (спасибо авторам), подумали над ними, переработали и учли в предлагаемой на ваш суд форме договора. Так что договор пока можно считать частично «захабренным».

Автопрефиксер — утилита нового поколения для добавления префиксов к экспериментальным свойствам из CSS 3. Она берёт с Can I Use последние данные о префиксах и популярности браузеров, читает ваш файл стилей, находит свойства и значения, которым действительно нужны префиксы и добавляет их.

Вы просто пишите обычный CSS:

a {
    transition: transform 1s
}

Автопрефиксер сам заменит нужные (и только нужные) свойства и значения (обратите внимание на -webkit-transform):

a {
  -webkit-transition: -webkit-transform 1s;
  -o-transition: -o-transform 1s;
  transition: -ms-transform 1s;
  transition: transform 1s
}

Эта утилита работает во время выкладки сайта на сервера (и на машине программиста во время разработки), так что не заметна для клиентов и не требует какой-то поддержки от браузеров.

Проблема

К сожалению текущие инструменты плохо решают задачу:

• Писать вереницы свойств руками — очевидно плохое решение. Такой код невозможно читать, легко забыть поправить остальные свойства при редактировании.
• В Sass и LESS вам нужно самому следить за актуальностью префиксов и копировать примеси из проекта в проект. К тому же примеси могут решить проблему только у свойств, а не у значений (например, calc()).
• Compass или Bourbon уже лучше, там список примесей хранится централизовано и его легче держать актуальным (но практика показывает, что обычно в примеси добавляют все префиксы не следя за актуальностью). Проблема значений всё так же не решена.
• Самая главная проблема Sass и LESS, что вам всё равно нужно постоянно думать «из CSS 3 это свойство или нет?» — и в зависимости от этого использовать примесь или нет. Эту проблему немного решил Stylus — у него синтаксис примесей не отличается от обычных свойств, так что префиксы добавляются невидимо. Впрочем, проблема актуальности и значений всё равно остались.
• Есть ещё скрипты добавления префиксов прямо в браузере, например Prefix Free, но лучше всего обрабатывать стили на этапе разработки и выкладки, а не повторять обработку каждый раз в браузере клиентов.

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

Текстовый редактор bootstrap-wysiwyg — это всего 1.5 Кб в минифицированном и сжатом виде и чуть больше 6 Кб исходного кода, базовые функции редактирования на основе execCommand, drag-and-drop для вставки изображений, поддержка стандартных горячих клавиш и ничего лишнего. Редактор работает в современных браузерах (Chrome 26, Firefox 19, Safari 6) и на мобильных платформах (IOS 6 iPad/iPhone, Android 4.1.1 Chrome). Зависимости — jQuery, jQuery HotKeys и Bootstrap.

Декомпиляция — процесс воссоздания исходного кода декомпилятором

Недавно я задался вопросом: Какой декомпилятор лучше?
Начал мучить Google, экспериментировать. В итоге нашел отличное решение. Как декомпильнуть любую программу и получить рабочие «исходники»? Об этом в сабже.

update: Мы ещё живы и наконец-то открыли продажи!готовим первую партию к продаже конце сентября.
Новая версия стала куда лучше и выглядит теперь вот так:


Подробности в нашем блоге.
/update

TL;DR (Abstract)

Мы сделали маленький «одноплатный» встраиваемый компьютер с хорошим набором периферии, в основном беспроводной (GSM/GPRS, NFC, Wi-Fi, GPS, Ethernet, etc). Рабочее название — Wiren Board (от Wireless Enabled)

Предполагается, что использоваться он будет для всяческой автоматизации — то есть в качестве «мозга» для оборудования. Если вы хотите сделать умное устройство, не разрабатывая целиком собственное сложное железо, то это для вас. Впрочем, для DIY наш компьютер тоже весьма полезен, и об этом направлении мы не забыли при разработке. Если понадобится дополнить чем-то специфическим — функциональность можно расширять готовыми модулями. Что ещё приятно, стоимость компьютера мы планируем сделать всего около $100.

Первая версия уже готова, открыт предзаказ.

Что привело нас к разработке встраиваемого компьютера, через какие этапы мы прошли, и что в итоге получилось — читайте дальше.

Я люблю desktop-приложения. Признаваться в этом нынче, похоже, стыднее, чем в связях с иностранной разведкой, но это так. Нет, это не значит, что я не люблю интернет-технологии. Более того, некоторые я не только уважаю, а даже более-менее знаю. Но, тем не менее, я скучаю по тем временам, когда программа писалась на одном компьютере, потом компилировалась и запускалась на других, разных компьютерах. Тогда везде (почти) была одна система — Windows с одной и той же API, почти не было проблем совместимости на уровне приложений, никто не материл разработчиков браузеров — все берегли нервы на разработчиков WinAPI, которые умудрялись создавать конфликты даже внутри нее одной. Но это я, конечно, иронизирую, а если серьезно — иногда и сейчас хочется написать просто desktop-приложение, да так, чтобы работало оно на всех популярных системах. Трудно? Если подумать и покопать, то не очень.

Еще я люблю языки высокого уровня с аккуратной архитектурой и строгой типизацией. Мои фавориты — Java и C#. Оба они предоставляют разработчику множество преимуществ по сравнению с C++, оба избавляют от ряда забот. Чем приходится платить? Тем, что таскаешь за собой тяжелую колоду, которая называется Oracle JVM, .NET или mono. Все три колоды весят сотни мегабайт и лицензию имеют такую, что каждый пользователь вынужден качать эту штуку сам, не путая при этом разрядность своего компьютера, а главное — программа на Java не может быть совместима со всеми версиями JVM разом, не так ли? И вот — мы приходим к тому, что просто скинуть программку другу (или миллиону друзей) и не заботиться о том, что она у него не запустится, не выходит. Приходится делать хитрые сетапы, вбивать костыли, и это я еще не упомянул .NET — однажды я видел у друга сразу 3 установленных версии, причем все три были нужны разным приложениям…

Стоп! А давайте напишем программу на Java, но так, чтобы она не требовала установки на машину какой-либо JVM, чтобы одним касанием собиралась под Windows, Linux и OS X и чтобы при этом занимала совсем чуть-чуть; так, чтобы никто даже не понял, что она написана, скажем, не на C. Невозможно? Совсем наоборот! (И нет, я имею в виду не gcj, который лишает Java всех ее прелестей. Рефлексия будет работать и даже сторонние jar вы сможете запускать).

Цель данного поста — помочь начинающему разработчику быстро освоится и спроектировать простенькую базу с помощью инструмента для визуального проектирования баз данных MySQL Workbench от компании Oracle и получить её ER-модель и SQL-дамп.

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

Уверен, такая задача знакома всем веб-разработчикам. В этой статье мы хотим поделиться нашим решением проблемы, опубликованным под открытой лицензией на ГитХабе.

Познакомьтесь с веб-сервисом Barberry (https://github.com/Magomogo/Barberry), который мы успешно используем уже около года. Суть сервиса в том, что он хранит оригиналы загруженных документов и способен по-разному отдавать их, конвертируя на лету.

Ни для кого не является секретом то, что в организациях установка приложений на клиентские компьютеры должна быть (или, если честно, то рекомендуется, чтобы была) автоматизированной. Естественно, комплексные продукты, например, такие как Microsoft System Center Configuration Manager, могут превосходно справляться с такой задачей, однако ведь всегда были, есть и будут организации, которые по той или иной причине не приобрели себе такой продукт. Поэтому приходится устанавливать программные продукты с помощью тех же штатных средств операционных систем Windows, и для выполнения такой задачи предпочтительными становятся функциональные возможности групповой политики.
Также все прекрасно знают и о том, что при помощи расширения клиентской стороны Group Policy Software Installation – GPSI, приложения можно развертывать на клиентские машины двумя методами: либо путем публикации только для пользователей, либо при помощи назначения для пользователей или компьютеров.

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

Я же хочу немного развеять часть мифов о сисадминском аутсорсинге, если позволите так его называть. Сам я являюсь работником такой же фирмы на протяжении 3х с хвостиком лет. Единственная оговорка – находимся мы не в Столице РФ, а в крупном по местным меркам городе N, являющимся столицей области. Конкуренция тут не такая сильная, но ответственность, как ни парадоксально, выше. Ну и ещё чуть-чуть о компании – сисадминский аутсорсинг (далее – сис. аутсорсинг, с позволения Читателя), это не основной профиль деятельности компании. Компания воюет на нескольких фронтах, вполне успешно надо отметить. А аутсорсинг вырос как побочная услуга, поддерживающая одно из основных направлений деятельности.

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

Предупреждение. Данный текст пользы для, а не холивара ради

Пост гнева.

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

Вчера, то есть 22 марта, увидел свет релиз 5 версии GitLab. GitLab — замечательный аналог таким продуктам, как GitHub, Bitbucket. Однако он устанавливается на ваш личный сервер и полностью подконтролен вам. Это отличное решение для компаний, занимающихся разработкой программного обеспечения, web студиям ну или просто тем, кто хочет иметь свой собственный git репозиторий.



Что же нового в версии 5.0? Для ознакомления с подробностями прошу под кат

Уважаемые коллеги,
особенно топ-менеджеры и владельцы IT-компаний, достаточно частым (если не абсолютно обыденным) является положение дел, когда в компании, занимающейся изготовлением софта, само ПО не проходит никакую процедуру регистрации.

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

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

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

В отсутствие регистрации это достаточно непростой процесс.

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

Я люблю Фотошоп. Честно-честно! Я работаю с ним каждый день уже лет десять. Нельзя переоценить влияние Фотошопа на отрасль цифровой графики — которая во многом определяет, как выглядит мир вокруг нас! Я практически уверен, что прямо сейчас в вашей комнате есть как минимум одна вещь, в дизайне которой принимал участие Фотошоп. И, конечно, картинки для этой статьи были подготовлены в Фотошопе!

В своей сфере Фотошоп — лидер. Его можно называть «стандартом» (что скорее хорошо) или «монополистом» (что скорее плохо). Но факт остается фактом — если вы работаете с любым видом цифровой графики, вам приходится мыслить терминологией Фотошопа и следовать идеям его создателей.

Признаться, Фотошоп — это не самая сложная компьютерная программа из существующих (поскольку, будем откровенны, цифровые изображения — это не самая сложная часть компьютерной науки). Однако, он все-таки весьма сложен. Причин несколько. Во-первых, в Фотошопе много функций и, следовательно, возможностей. Во-вторых, он стар (он очень стар, он… ну вы понимаете :-) — почти моего возраста! Такая долгая история разработки означает, что создатели Фотошопа прошли долгую дорогу, и у них не было возможности пересмотреть основные концепции или переделать какие -то вещи заново. Совместимость и все такое. И потом, зачем чинить то, что не сломалось?

Images by about.com

Однако, сегодня ночью меня посетила идея… нет, ИДЕЯ! И теперь она сидит у меня в голове, стучится и просится наружу, хочет быть рассказанной, опубликованной и обсужденной. А что может быть лучше интересного обсуждения!

Итак...

Всем привет!

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

---

Java — это язык с мощными стандартными возможностями, но «Большая сила налагает большую ответственность». Я видел много java-кода, в котором чрезмерно (и зачастую — неправильно) использовались «редкие» свойства языка, в то время как основы основ были почти полностью проигнорированы. Эти наблюдения и послужили стимулом к написанию статьи.

Это не список обязательных к использованию каждым программистом особенностей языка. Скорее наоборот. Я разделил их на 3 группы: "для каждодневного использования", "для периодического использования" и "только для фреймворков и библиотек!". Правило простое: если вы понимаете, что используете указанные свойства чаще, чем рекомендуется, то, скорее всего, ваш код развивается по неправильному пути. Если же наоборот — вы редко используете какие-то свойства, чем я рекомендую, значит вы упускаете какие-то интересные и важные возможности языка.

Обратите внимание, что я говорю о разработке типичных серверных бизнес-приложений (JVM, JDK, вот это все) и не даю рекомендаций относительно каких бы то ни было фреймворков.

Хочу рассказать о своем опыте использования Google Maps в приложении на JavaFX. Рассмотрим загрузку карты в приложение и вызов Google Maps JavaScript API v3 для загруженной карты из своего кода на Java.

Конец 2012 года прошел в суматохе, и каким-то образом я упустил из внимания две важные новости: в декабре вышел GitLab 4.0, а на середину ноября пришелся релиз GitLab Continuous Integration Server.

GitLab — это замечательное FOSS решение для хостинга git-репозиториев внутри закрытой инфраструктуры. Функционал во многом аналогичен GitHub, в частности доступны базовые возможности администрирования и разделения полномочий между пользователями, issue трекер, вики, code review и мердж реквесты (аналог пулл-реквестов на GitHub). И внеочередной плюс теперь, как по мне — это интеграция с GitLab CIS.

GitLab CIS — если GitLab послужит Вам заменой GitHub, то GitLab CIS призван стать заменой Travis CI. Набор фич соответствующий: запуск по git push, отдельные билды под бранч, интеграция с любыми git-репозиториями и бейджик со статусом текущего билда.

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

Что примечательно, работу ведут и курируют скромные украинские парни Дмитрий Запорожец и Валерий Сизов.

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.



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

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?