to post messages and comments.

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

Кстати, отладка Service Workers в Firefox то еще удовольствие.
Фигово, что для APNS надо покупать сертфикат разработчика.

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

Вчера так вообще перл выдал в 23 часа. В чате вопрос от него "А релиз-то когда сегодня". Нормалек, думаю. Среди ночи я узнал, что сегодня будет релиз. Оказывается, он еще неделю назад договорился с заказчиком о релизе, а мы ни сном ни духом. Ай да молодец. Ни в доках, ни в переписках ни слова о том, что релиз должен был быть в ту дату. Ну просто мастер.

Но это еще полбеды. В релиз должны были войти задачи, которые были поставлены за 30 минут до его вопроса! Не, ну мистер, однозначно, знает толк в ведении дел.

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

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

Привет Жуйк!
Подскажи, пожалуйста. Вот я хочу вести проект, мне нужно вести по нему документацию, что именно и где находится и за что отвечает в техническом плане. Это нужно разработчикам, а не пользователям. Проект веб. Какие есть для этого программные средства? Лучше свободные... Спасибо!

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

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

Блин, вот хорошо, когда ТЗ подробно расписывают за тебя. А так знаешь, что продукт в случае сбоя способен причинить вред человеку, и вроде всё предусмотрел, но постоянно находятся какие-то новые возможности для членовредительства =(

Первые 13 книг — чтиво настоятельно рекомендуемое всем, кто соприкасается с разработкой софта или ещё только планирует это:

Т.Демарко — Балдеющие от адреналина и зомбированные шаблонами. Паттерны поведения проектных команд
Д.Платт — Софт — отстой! И что с этим делать
С.Макконнелл — Профессиональная разработка программного обеспечения
А.Купер — Психбольница в руках пациентов. Алан Купер об интерфейсах Почему высокие технологии сводят нас с ума и как восстановить душевное равновесие (исправленное издание)
Э.Салливан — Время — деньги. Создание команды разработчиков программного обеспечения
Э.Стеллман — Идеальные команды. Вдохновляющие и предостерегающие рассказы ветеранов тимлидинга
Р.Гласс — Креативное программирование 2.0
Р.Гласс — Программирование и конфликты 2.0. Теория и практика программной инженерии
Дж.Мараско — IT-проекты фронтовые очерки
Д.Мак-Карти — Программируем командный дух

Д.Спинеллис — Идеальная архитектура. Ведущие специалисты о красоте программных архитектур
С.Сеов — Проектируем время. Психология восприятия времени в программном обеспечении
А.Купер — Алан Купер об интерфейсе. Основы проектирования взаимодействия

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

М.Фаулер — Рефакторинг улучшение существующего кода
С.Макконнелл — Совершенный код (2-е издание)
П.Гудлиф — Ремесло программиста. Практика написания хорошего кода
Р.Мартин — Чистый код. Создание, анализ и рефакторинг

М.Фаулер — Архитектура корпоративных программных приложений (исправленное издание)

Эр.Фримен — Паттерны проектирования
Э.Гамма — Приемы объектно-ориентированного проектирования
Г.Буч — Объектно-ориентированный анализ и проектирование с примерами приложений

К.Бек — Экстремальное программирование. Разработка через тестирование
Дж.Нильссон — Применение DDD и шаблонов проектирования

Ф.Брукс — Мифический человеко-месяц или как создаются программные системы (юбилейной издание)
Э.Йордан — Смертельный марш

Не понимаю разработчиков, которые мучаются с экранированием кавычек внутри строк. Я про вот это:
"So he went for another \"lesson\".", 'People\'s intention to brag about things was always funny to me.'
Люди, почему бы вам просто не писать те символы, которые там на самом деле должны быть? То есть:
"So he went for another “lesson”.", 'People’s intention to brag about things was always funny to me.'
Раскладка третьего уровня настраивается на раз-два! Тогда и экранировать ничего не придётся.

Давно не обновлялся :D

добавлено 56 наборов изменений с 10115 изменениями в 9649 файлах
(используйте 'hg update' чтобы получить рабочую копию)
6404 файлов обновлено, 0 слито, 355 удалено, 0 c конфликтами

Вернулся с конференции разработчиков игр. Куча интересных лекций, знатные девушки, представляющие продукты aggro, mail.ru games, eve online, glyph и д.р. и круглый стол с основателем компании obsidian ent. Feargus Urquhart <en.wikipedia.org>-том дали огромный вдохновляющий пинок вперед.

Ну а, собственно, проблема, которую я пытаюсь решить в MIUI заключается в том, что android:attr/textColorPrimary и android:attr/textColorSecondary в MIUI по прежнему определяют белый и серый цвета. Тогда как цвет фона на всех окошках — далеко не черный.

Что, цвета бэкграундов во всех стилях тоже определять?
Как сделать UI с использованием системных цветов, выглядящий одинаково прилично во всех Андроидах?
Почему вообще, при наличии мощнейней системы стилей, пользоваться системными стилями почти невозможно?

Поймал вот такое. Похоже, что любой SwitchPreference в ICS падает при клике, если включено Accessibility.
А Accessibility у меня оказалось включено благодаря Power Toggles (они там какой-то костылик прикрутили, чтобы в Андроидах древнее JB уведомление показывать в начале)
ERROR/AndroidRuntime(26395): FATAL EXCEPTION: main
java.lang.NullPointerException
at android.widget.Switch.onPopulateAccessibilityEvent(Switch.java:370)
at android.view.View.dispatchPopulateAccessibilityEventInternal(View.java:3992)
at android.view.View.dispatchPopulateAccessibilityEvent(View.java:3982)
at android.preference.TwoStatePreference.sendAccessibilityEvent(TwoStatePreference.java:197)
at android.preference.SwitchPreference.onBindView(SwitchPreference.java:108)

Поймал java.lang.VerifyError. У меня есть метод, использующий классы, отсутствующие в данной версии Андроида (пишу под ICS, а хочу, чтобы запускалось в 1.5). При этом метод в старых Андроидах просто не должен вызываться. Он и не вызывается, просто отсутствующий класс объявлен как возвращаемый из метода, в результате этот класс не проходит валидации.
Решение: убрать сильно новые классы из сигнатур методов.

Погодных уведомлений множится. Вот очень интересный вариант: play.google.com
Как автор оригинального приложения вижу следы моей идеи. Нотификация сделана интересно. Но сам показ уведомления каким-то образом поломали, у меня — глючит.

А вообще насколько общим местом в Андроиде является использование Switch в настройках?
Типичный пример: настройки вайфая в ICS. Там строчки Wi-Fi и Bluetooth, по которым можно тыкнуть и перейти в раздел соответствующих настроек, а можно и просто по свичу тыкнуть — включить/выключить.
Вот пытаюсь в своем приложении сделать такую систему и обнаружил, что эти чертовы свичи занимают половину ширины экрана. А значит, пару слов в названии свойства уже не вставишь, только одно и короткое (ага, Wi-Fi и Bluetooth).
Можно ли заменить свич на старый добрый чекбокс? Будет ли понятно юзеру, что можно тыкнуть по надписи, а можно и по чекбоксу?

#kotlin #groovy #scala

Пересмотрел презентацию Андрея Бреслава о языке Котлин.
Получается, что они пытаются занять нишу между груви и скалой.
Котлин — статически типизированный язык, и при этом имеет меньше всяких неявных вещей.
В отличие, от Скалы, эти неявности проще диагностировать.
Если по простому, то всегда можно снавигироваться к той или иной реализации прямо в IDE.
В Scala, во многих случаях, без дебаггера не разберёшься откуда применился метод.

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