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

Сразу оговорюсь, что примеры приводятся применительно к языку C# и платформе .NET. Соответственно, в других языках/платформах подходы и реализации могут отличаться.

Итак…

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



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

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

«Хочу программировать под iPhone — говори, что почитать...»
Любимая девушка

Когда решаешься заняться разработкой под iOS, то трудно выбрать литературу и ресурсы, которые действительно были бы полезны. Хорошо еще, что Apple предоставляет множество учебных материалов и программ с открытым исходным кодом в своем центре для разработчиков. В остальных книжках можно если и не утонуть, то порядочно захлебнуться. Сейчас я жалею, что потратил время на пару «мануалов». Не буду делать им антирекламу, а лучше порекомендую хорошие материалы по программированию под iOS.

Под катом книги, видеокурсы и блоги, которые будет полезно прочитать/посмотреть.

Разработка программного продукта знает много достойных методологий — иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне.

Я разместила иконки курсов Стэнфордского университета по разработке приложений на iOS в обратном хронологическом порядке. На первом месте стоит иконка Swift — нового языка программирования для создания приложений на iOS, объявленного на WWDC 2014. Кроме Swift реализована новая версия iOS — iOS 8. Уже известно, что Стэнфордский университет запустит зимой 2015 года новый курс CS193P с неизвестным пока названием (может быть будет что-то вроде «Developing iOS 8 Apps for iPhone and iPad»). Лектор тот же — профессор Paul Hegarty.
В традиции Стэнфорда выкладывать курс CS193P на iTunes U в виде бесплатного курса обучения, но делают это они со сдвигом во времени, чтобы не мешать платному обучающему процессу, так что в феврале-марте 2015 года (как это было в 2013 году) можно ожидать постепенное появление лекций на iTunes U. Так что время есть.
Я прошла почти все курсы профессора Пола Хэгарти — от iOS 5 до iOS 7 — до самого конца (смотри Github ).
Для подготовки к перспективному курсу по iOS 8 разместила на своем сайте «Разработка iOS приложений» неавторизованные конспекты лекций, тексты домашних заданий и примеры их решения на русском языке для последнего доступного в настоящее время обучающего курса «Developing iOS 7 Apps for iPhone and iPad», запущенного Стэнфордским университетом в семестре «осень 2013 — зима 2014 года» на iTunes U.

Сегодня я хочу вам рассказать о том, как однажды познакомился с языком программирования Swift и решил написать на нем приложение для социальной сети ВКонтакте под OSX (которое, к сожалению, до сих пор не закончено). С какими подводными камнями мне пришлось столкнуться при обуздании, на тот момент, нового языка и скрещивании его с VK.API. Поделиться с общественностью результатом того, во что именно все это вылилось и попытаться обосновать, зачем нужно было придумывать очередной велосипед в виде библиотеки для работы с VK.API.
Если кому-то это интересно, то добро пожаловать под кат.

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

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

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

CocoaPods — это очень мощный инструмент, имеющий статус must have для любого iOS Developer'а. С помощью него мы можем легко, быстро и просто подключать различные вкусные тулзы, утилиты и библиотеки, которые значительно облегчают нам жизнь при разработке приложений. Но всяким инструментом надо уметь пользоваться и CocoaPods не исключение.
Под катом информация, которая позволит начать освоение этого инструмента (основано на том, что изложено в документации и собственном опыте). И так, дорогой читатель, отложи в сторону микроскоп, хватит уже им гвозди заколачивать и продолжай читать.

Disclaimer:
Данная статья представляет собой вольный художественный пересказ-перевод первой главы книги "App Savvy
Turning ideas into ipad and iphone apps customers really want"

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


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

Привет %username%! У нас отличные новости: вышла официальная версия NinjaMock — онлайн-сервиса для создания прототипов. Теперь ты можешь рисовать отличные прототипы веб- и мобильных приложений совершенно бесплатно!

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

Функциональное программирование вряд ли можно назвать новым явлением. Еще в начале 90-х, когда я учился в университете, нам нередко приходилось писать что-то на LISP. Казалось бы, 25 лет прошло – но ведь уже тогда этот язык программирования был старше меня.

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

Но, похоже, ни один функциональный язык не претендует на звание общепризнанного. Я имею в виду своеобразную всемирную гегемонию C в 70-х, который позже передал корону C ++, Java, а со временем и JavaScript. Ни один из претендентов второго эшелона (Python, PHP, Perl, Ruby, C# ...) не попадал в категорию функциональных.

Когда я начала заниматься Ардуино, мне казалось, что весь мир только и делает, что занимается тем же. На самом деле оказалось, что, как и мне, многим просто трудно начать, «въехать» в саму тему. Поэтому я решила написать быстрый гайд для того, чтобы вы сразу могли взять несколько компонентов и попробовать эту игрушку. Вероятно, после прочтения, вы даже сразу во многом поймёте что к чему и без моих будущих постов. Итак.


Если вы не попробовали Ардуино только потому, что не можете начать, не зная что к чему, я сейчас спасу вас.

Корпорация IBM уже довольно давно сотрудничает с Apple. Взаимодействие двух компаний касается многих сфер, и одна из них — программирование. Причем программирование на Swift. Дело в том, что корпорация Apple сделала исходный код языка программирования Swift открытым. А в Mobile Innovation Lab от IBM создали специальную песочницу для разработчиков, которые хотели бы познакомиться со Swift.

Благодаря открытию кода, разработчики, которые создают приложения для iOS, OS X и watchOS, могут без проблем обходить существовавшие ранее ограничения, дополняя многие функции при необходимости. Apple для привлечения широкой аудитории опубликовала достаточно массивную библиотеку различной документации, которая позиционируется как пособие для начинающих программистов. Стоит отметить, что лицензируется Swift под лицензией Apache 2.0. Эта лицензия позволяет использовать программное обеспечение для собственных целей, и платить Apple не требуется.

Перевод от Alconost

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



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

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



Разные цвета? Это смены направлений: из разработки в продуктовый менеджмент, из продаж в основатели стартапа и т.п.

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

Принимая во внимание все вышесказанное, позвольте дать вам 15 советов о ваших карьерных выборах, кодинге, амбициях и всем остальном.

По просьбе tulskiy делаю вольный перевод частей официальной документации GitHub'а Fork A Repo и Send pull requests.

Итак, что же такое «запрос на включение (сделанных вами изменений)» (именно так я перевёл pull request)? В официальной документации гитхаба говорится следующее:

Pull request'ы позволяют вам рассказать другим о тех изменениях, которые вы разместили в своём GitHub-репозитории. Как только pull request отправлен, заинтересованные стороны рассматривают ваши изменения, обсуждают возможные правки или даже добавляют дополняющие коммиты, если нужно.

Говоря своим языком: Посылая pull request, вы говорите автору изначального репозитория (и всем заинтересованным лицам): «Смотрите, что я сделал, не хотите ли принять мои изменения и влить их в проект?»

Относительно недавно мне посчастливилось присоединиться к команде разработки Bitbucket Server в Atlassian (до сентября он был известен как Stash). В какой-то момент мне стало любопытно, как этот продукт освещён на Хабре, и к моему удивлению, нашлось лишь несколько заметок о нём, подавляющее большинство которых на сегодняшний день уже устарело.

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

Позвольте начать с перевода статьи Тима Петтерсена «A better pull request» о том, как должен выглядеть pull request, чтобы наиболее эффективно решать возложенную на него задачу.

С развитием смартфонов в последние годы было разработано много инструментов, чтобы упростить жизнь разработчикам, обеспечив их максимальной производительностью и качеством. Занимать лидирующие позиций в App Store сегодня не простое задание. А научить ваше приложение масштабироваться еще сложнее. Когда приложением пользуются миллионы пользователей, вы должны следить за приложением и при необходимости выполнять все операции моментально. Поэтому одной из проблем, с которой сталкиваются многие разработчики, является Database. Она действительно вызывает сильную головную боль для каждого из нас, и я думаю, что сегодня у вас есть только два варианта: SQLite и Core Data. Я был большим поклонником Core Data и его способностью работать с записями и сохраняющимися данными, но я понял, что впустую трачу много времени, работая с ним при разработке приложений. Недавно, я столкнулся с Realm, новой лучшей заменой SQLite и Core Data.

2006 год. На форуме специалистов SQL неожиданно поднимается вопрос о целесообразности моделирования бизнес-процессов в CRM-системах. Звучат слова: долго, дорого, Siebel, не нужно, сложно.
2014 год. Все чаще клиенты просят посоветовать CRM с возможностью построения и запуска бизнес-процессов. В чем причина? Первое подозрение — где-то услышали и теперь тянутся за модой. На вопрос «Зачем?» поступает взвешенный ответ: «Устали от беспредела и путаницы в организации работ. Хотя бы в часто повторяющихся действиях нужен порядок». Нельзя не согласиться с тем, что основное назначение регламентации бизнес-процессов в компании — именно порядок. Признайтесь, приятно осознавать, что многие процессы в организации проходят четко, слаженно, быстро, с минимальной нервозностью.

Молодой программист, едва закончивший или ещё даже не закончивший ВУЗ, готов свернуть горы, учиться, учиться и ещё раз учиться и ему близлежащее будущее кажется таким:



Но более опытные товарищи знают, что на самом деле на его пути давно уже заботливо разложены грабли и путь от Junior'а к Senior'у выглядит как-то так:



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