Вероятно, в качестве рождественского и новогоднего подарков, Microsoft запустила акцию Skype Collaboration Project, в рамках которой Skype дарит пользователям возможность на весь следующий год возможность пользоваться функциями групповой работы (видеочат и разделение экрана), а также отключить отображение рекламы. Еще вы получаете годовой абонемент на обмен картинками рабочего стола в групповых звонках, полным отсутствием рекламы и бесплатную техническую поддержку на период прохождения акции.

Для участия в акции переходим по этой ссылке и вводим туда почту на которую придет письмо с кодом (Вводить почту на которую зарегистрирован аккаунт скайпа не обязательно).

Я люблю две вещи: Intellij IDEA и чистый код (Clean Code).
IDEA создана для чистого кода. Многие настройки по умолчанию уже стимулируют вас писать как надо.


Но она всё ещё не идеальна.
Когда я устанавливаю новую копию IDEA, я пробегаю по настройкам и выставляю свои любимые галочки.
Хочу ими с вами поделиться в надежде, что когда-нибудь и они станут стандартом.

От переводчика

Искали тут двух русскоязычных разработчиков — на iOS и на C++ под Windows. Видел десятки выполненных тестов. Разница в знании ООП между представителями двух платформ — огромная. На C++ обычно красивый расширяемый код, как само собой разумеющееся. На Objective C картина удручающая. Почти все iOS-кандидаты не знали ООП дальше своего носа NSString'ов и AppDelegate'ов.

Понятно, что плюсы учат по Страуструпу и «банде четырёх», а Objective C — больше по туториалам и Stack Overflow. Фастфуд-обучение не оставляет места на фундаментальные вопросы… Но такой разницы я не ожидал.

Поэтому я перевёл пост, в котором даны начальные сведения о шаблонах проектирования с примерами на iOS… «начальные»? Ага, значит, будет продолжение? Нет, не будет. Дальнейшие сведения вы получите из опыта, из попыток организовать процесс написания кода с помощью паттернов. Сначала не будет получаться, вероятно, фасад здания будет торчать из дымовой трубы, но потом придёт понимание, где какие приёмы реально помогают.

Качественная разработка ПО — творческий процесс, уникальный для каждой конкретной головы. Поэтому не существует общей инструкции: if (A and (B or C)) then use Pattern_N;

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


Хочешь вовлечь пользователя? Общайся с ним на его языке!

Хотя вопросы «состыковки» текста с кодом, несомненно, важны, один момент – очень деликатный! – часто остается без внимания, и это – качество перевода. Почему? Для этого есть объективные причины.

Во-первых, локализация мобильных приложений имеет свои особенности. Большие хардкорные проекты издатель обычно переводит, например, с английского/корейского на русский. У «телефонных игр» другая судьба. Им необходимо привлечь внимание как можно большего количества пользователей по всему миру, поэтому с базового русского или английского их, наоборот, выгодно локализовывать на максимальное количество языков.

И здесь разработчики сталкиваются с ожидаемым препятствием – мало кто может свободно читать и редактировать тексты на десяти-двенадцати языках. А если и может – этот человек по праву оценивает свои квалификации на вес золота. Искать такого специалиста можно долго, и охота эта будет кровавой.

Вторая причина – приоритет кода перед текстом. Логично, что юзабилити, монетизация и графика ставятся во главу угла. В конце концов, пользователь приходит в игру не для того, чтобы читать! Да на буквы эти и внимания никто не обратит! (Возьмите конфетку если вы разработчик, и такие мысли никогда не приходили вам в голову – значит, вы на самом деле исключение из правил).

В эту ловушку попадаются многие – задачи по подготовке локализации и ее тестированию часто откладываются на самый последний момент.

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

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

Как же добиться того, чтобы локализация не просто налезла на приложение, но и сидела на нем, как влитая?

Итак, в мае 2013 года на хабре появилась статья «Сколько стоит сделать браузерную игру», где господин viacheslavnu пробовал посчитать — какая сумма средств потребуется на создание и продвижение, казалось бы, простецкой игры для офисного потребителя. Если кто не помнит – сумма получилась в районе 25 миллионов рублей. На тот момент я сам несколько скептически отнесся к указанной сумме, но чем ближе подходила дата нашего старта, тем больше я убеждался, что даже для таких проектов нужны «особенные» вложения капитала, которые не всегда по карману разработчикам без инвестора со стороны.

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

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

Что у нас было в 2013

Одна из самых радостных для нас новостей в 2013 году прозвучала на Google I/O: Google анонсировал preview-версию Android Studio, новую среду разработки приложений под Android. Android Studio разрабатывается в сотрудничестве с JetBrains на основе IntelliJ IDEA Community Edition. IntelliJ IDEA 13 — это первый мажорный релиз, включающий в себя то новое, что возникло в результате этого сотрудничества.

Этой весной мы сделали и поддержку новой Java 8.

Мы остаемся привержены идее вдумчивой интеграции одних наших инструментов с другими: например, мы обновили плагины для совместной работы IntelliJ IDEA с TeamCity, продолжаем разрабатывать наши новые продукты, используя опыт создания платформы IntelliJ. Так, в сентябре 2013 мы анонсировали наш новый продукт — UpSource, серверную платформу для работы с кодом в браузере с присущими нашим инструментам возможностями: навигацией, find usages, показом изменений в коде и анализом кода.

И сегодня… Буквально пять минут назад… Па-пам! Мы выпустили IntelliJ IDEA 13.

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

Именно таким вопросом я задался сегодня утром, придя на работу. Вроде бы все признаки программиста есть: код пишу уже не первый год, за плечами не один проект (как провальные так и успешные), разбираюсь в структурах данных, алгоритмах и их оценке, знаю, как работают сети и сам компьютер вплоть до железного уровня, знаю и использовал скрам, канбан и иже с ними. Честно ходил на конференции послушать, а так же честно выступить. С огоньком в глазах читал лекции студентам и рассказывал каково это быть программистом. Многие из них пошли на работу программистами, самых толковых я забирал себе в команду. Читал тренинги по паттернам, JavaScript и .NET, проводил хакатон, участвовал в хакатоне, и радовался как ребенок от этих самых хакатонов.

Бывает, наступает момент, когда нужно следить, не развалился ли лишний раз интерфейс мобильного приложения. Чтобы решить эту проблему используются автоматические тесты. Для веб страниц считается общепринятой практикой использовать Selenium Web driver, поэтому для мобильных приложений я искал похожие вещи. И, на счастье, таких нашлось немало, в них используется Selenium WebDriver JSON Wire Protocol.

Это перевод статьи.

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

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

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

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

Джон Стивенсон в своей статье пишет: «Да, ХХХ, был таким отличным тестером, но он был вынужден перейти в разработчики, чтобы иметь возможность развиваться в компании» и именно эту фразу я слышал в той или иной форме несколько раз. В нашем случае это был переход либо в разработчики, либо в управляющих проектом. Оба варианта рассматривались в качестве единственного реального прогресса для тестировщика. //Примечание переводчика: не совсем ясно, почему игнорируется путь QA Engineer -> Senior QA Engineer -> Lead QA Engineer. Но оставляю это на совести автора.

Это сделало меня грустным.

Хабралюди, добрый день!
Сегодня хочу начать написание ряда лекций с практическими заданиями по книге Михаеля Привата и Роберта Варнера «Pro Core Data for iOS», которую можете купить по этой ссылке. Каждая глава будет содержать теоретическую и практическую часть.



Содержание:

• Глава №1. Приступаем (Практическая часть)
• Глава №2. Усваиваем Core Data (Практическая часть)
• Глава №3. Хранение данных: SQLite и другие варианты
• Глава №4. Создание модели данных
• Глава №5. Работаем с объектами данных
• Глава №6. Обработка результатирующих множеств
• Глава №7. Настройка производительности и используемой памяти
• Глава №8. Управление версиями и миграции
• Глава №9. Управление таблицами с использованием NSFetchedResultsController
• Глава №10. Использование Core Data в продвинутых приложениях

О Bitcoin я узнал относительно недавно, но он меня сразу подкупил своей идеей p2p. Чем глубже я зарывался в их Wiki, тем больше проникался этой идеей. Ее реализация красива и элегантна с технической точки зрения.

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

Продолжаем нашу серию статей по мотивам опросов: на этот раз мы решили измерить расхождение между тем, как представляют рабочий день программиста студенты-технари, и тем, как все происходит на самом деле. Студенты МГТУ им. Баумана, которые учатся в Технопарке, снова согласились ответить на наши вопросы.

Для этого мы провели небольшое исследование, в ходе которого ожидаемо выяснилось, что не все представления о «сферическом рабочем дне в вакууме» совпадают с реальностью. Студенты готовы программировать по 790 часов в год при условии, что половину рабочего времени будут проводить в социальных сетях.

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

Вопрос программистам: Представьте себе свой типичный рабочий день. Какой процент времени в среднем занимает каждая из перечисленных активностей?

• Обдумываю задачу, ищу пути решения
• Изучаю информацию, читаю маны
• Пишу код
• Тестирую, ищу баги
• Участвую во встречах, планерках, брейнштормах, провожу собеседования
• Читаю Хабрахабр, Роем и другое полезное в интернете
• Читаю / пишу письма, ставлю / читаю таски в трекере
• Сижу в социальных сетях
• Общаюсь с коллегами по не рабочим вопросам
• Ем, пью, сплю

Далее для сравнения мы собрали ответы студентов Технопарка.

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

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

Решил все-таки написать статью про SQLite, в которой хочу обобщить свой 3-х летний опыт использования этой БД под Windows. Вижу, что тема популярная, но информации мало.

Часть 2
Часть 3

Небольшая вводная.

Эта статья не для начинающих программистов.
Она не является учебником по SQL.
Она не агитирует использовать SQLite.
Она не агитирует не использовать SQLite.
Статья написана в виде вопросов от гипотетического новичка в SQLite и ответов на них (поскольку информации очень много и так хоть немного проще ее структурировать).

Если не знаешь, надо не бояться, а узнавать.
Айн Рэнд “Атлант расправил плечи”



Добрый день, меня зовут Игорь Томич и я лектор курсов iOS-разработки и сооснователь онлайн курсов Master Up. Это мой первый пост в наш корпоративный блог, в котором я решил поделиться советами для начинающих iOS-разработчиков. Свое первое приложение для iOS я начал писать в начале 2009 года, а в мае 2012 году провел первый курс обучения по рарзработке под эту же платформу и к этому времени у меня скопилось достаточно “часто повторяемых ошибок” и путей их решения.

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

Ставим задачу

Кого ищем? Ищем эффективных бойцов. Известно, что эффективность программистов со схожим опытом может отличаться в 10 раз (Ф. Брукс) или даже в 27 раз (Р. Гласс). Сразу, оговорюсь, эффективность это не только количество трупов врагов реализованных требований к ПО на единицу трудозатрат, но и умение результативно взаимодействовать с окружающими. Это важно, потому что по моим наблюдениям 50% проектных человеко-часов тратится на коммуникации. У нас это называется «синхронизация ментальных моделей».

Поэтому задача, которую ставим себе при проведении технического собеседования это постараться оценить эффективность бойца.


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

От переводчика: данный текст даётся с незначительными сокращениями по причине местами излишней «разжёванности» материала. Автор абсолютно справедливо предупреждает, что отдельные темы могут показаться читателю чересчур простыми или общеизвестными. Тем не менее, лично мне этот текст помог упорядочить имеющиеся знания по анализу сложности алгоритмов. Надеюсь, что он окажется полезен и кому-то ещё.
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.

Опубликовано ранее:
Часть 1
Часть 2

Логарифмы

Если вы знаете, что такое логарифмы, то можете спокойно пропустить этот раздел. Глава предназначается тем, кто незнаком с данным понятием или пользуется им настолько редко, что уже забыл что там к чему. Логарифмы важны, поскольку они очень часто встречаются при анализе сложности. Логарифм — это операция, которая при применении её к числу делает его гораздо меньше (подобно взятию квадратного корня). Итак, первая вещь, которую вы должны запомнить: логарифм возвращает число, меньшее, чем оригинал. На рисунке справа зелёный график — линейная функция f(n) = n, красный — f(n) = sqrt(n), а наименее быстро возрастающий — f(n) = log(n). Далее: подобно тому, как взятие квадратного корня является операцией, обратной возведению в квадрат, логарифм — обратная операция возведению чего-либо в степень.

От переводчика: данный текст даётся с незначительными сокращениями по причине местами излишней «разжёванности» материала. Автор абсолютно справедливо предупреждает, что отдельные темы покажутся чересчур простыми или общеизвестными. Тем не менее, лично мне этот текст помог упорядочить имеющиеся знания по анализу сложности алгоритмов. Надеюсь, что он будет полезен и кому-то ещё.
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.

Введение

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

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