Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Архипенков Сергей — эксперт в управлении разработкой ПО, более 30 лет в разработке ПО, PMP® PMI, вице-президент Гильдии менеджеров программных проектов. Активный «продвигатор» и «задвигатор» теории и практики управления проектами и людьми в проектах по разработке ПО. Активный заседатель программных комитетов. Из последнего — председатель программного комитета конференции «Software Project Managment Conference» (ноябрь, Санкт-Петербург).

Ниже опубликован доклад Сергея с конференции CodeFest, на тему «Теория и практика адаптивного управления проектом».

Большинство прикладных приложения под iOS таким или иным образом используют UIViewController'ы. Там где UIKit фрэймворк — там и UIViewController'ы. Их много, они повсюду, они сидят в засадах и выглядывают из-за каждого угла. Поэтому, любой программист под iOS — будь он зеленым новичком, едва ступившим на тропу программирования, либо матерым профессионалом своего дела, должны знать о UIViewController'aх все.

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

Так вот. В данном посте, я еще раз расскажу о жизненном цикле UIViewController'ов, расскажу о том, что и где стоит делать, и в каком случае. Пост ориентирован на разработчиков разных уровней, так что кто-то узнает для себя что-то новое, а кто-то найдет повод отпинать моменты, на которые стоит обратить внимание Junior'ов в команде.

Всех заинтересовавшихся, прошу

В прошлом посте мы писали о том, как Островок.ru привлёк инвестиции размером 1 млн долларов от лучших инвесторов всего за 6 недель, имея только идею.

Мы получили очень много положительных отзывов на тот пост. Но в нём был существенный недостаток: мы описывали процесс с точки зрения нашего предыдущего опыта и связей. Большинство из этих рекомендаций неприменимы к вопросу о том, как начать в России свой бизнес, не имея связей и опыта.

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

На UpStartConf – секции о рынке инвестиций и стартапов в рамках РИФа-2011 основатели Островок.ру рассказывали о том, как привлечь в Рунет мировых инвесторов.

Эксперты, инвесторы и IT-предприниматели Рунета сошлись в едином мнении, что на российском интернет-рынке нет публичных кейсов стартапов, нет обучения для начинающих веб-предпринимателей, что неблаготворно влияет на рынок. В этом посте репатрианты Кирилл Махаринский и Сергей Фаге презентуют кейс по привлечению инвестиций на примере проекта Островок.ру

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

Вступление окончено, переходим к советам!

Мне повезло: я побывал по обе стороны баррикад и теперь знаю, что и как делает заказчик на проектах разного уровня и что делает фрилансер, чтобы получить или провалить такой проект. В итоге я уверен, что 95% фрилансеров говорят с заказчиком на разных языках.

Осторожно, butthurt.

Вы — ProductOwner и отвечаете за группу веб-проектов. Когда сайты висят, недоступны или Клиентам выводится отладочная информация типа «Exception in object COrderController constructor… » — вам начинают звонить на мобильный, писать в твиттер и т.п.:

• топ-менеджер (или генеральный)
• коллеги, некоторые злорадствуя
• наши уважаемые Клиенты

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

Любой приказ, который может быть неправильно понят, понимается неправильно (Армейская аксиома)

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

В последнее время мне везет натыкаться на интересные статьи для перевода. На этот раз – статья на HTML5Rocks о производительности HTML5 canvas. Автор пишет о некоей стене, в которую упираются разработчики при создании приложений. Какое-то время назад в нее уперся и я при портировании старой-доброй игры на canvas.

К сожалению, графики в оригинале вставлены через iframe. Я мог бы сделать снимки и разместить их изображения, но сам автор позиционирует графики актуальными и такими, которые будут обновляться, потому я просто разместил на них ссылки. Приятного чтения!

1. Вступление
2. Тестирование производительности
3. Предварительно отрисовывайте в виртуальный canvas
4. Группируйте вызовы
5. Избегайте ненужных изменений состояния
6. Отрисовывайте только разницу, а не весь холст
7. Используйте многослойных canvas для сложных сцен
8. Избегайте shadowBlur
9. Различные способы очистить экран
10. Избегайте нецелых координат
11. Оптимизируйте анимации с помощью 'requestAnimationFrame'
12. Большинство мобильных реализаций canvas – медленные
13. Заключение
14. Ссылки

Вступление

HTML5 canvas, который начинался, как эксперимент компании Apple, – наиболее широко распространенный стандарт для 2D режима непосредственной графики в интернет. Многие разработчики использую его в широком круге мультимедиа проектов, визуализаций и игр. Как бы то ни было, с ростом сложности приложений, разработчики нечаянно натыкаются на стену производительности.

Приветствую всех! Решил поведать вам свою историю, возможно, кому-то это будет интересно. А если это кого-то вдохновит на подвиги – значит, я не зря взялся за эту статью.

Коммерция

Недавно стукнуло 3 года с того момента, как я стал профессиональным гейм-девелопером. Слово «профессиональный» здесь не в смысле «крутой разработчик», а в том плане, что это является моим единственным источником дохода.
Итого, с 2009-го по 2011-й было разработано 7 игр. Количество геймплеев со всех игр стремится к 100 миллионам, а доходы с этих игр – к [вырезано цензурой]. Но об этом я сегодня писать не буду, ибо в этом мало романтики, и слишком много цифр. Сегодня речь пойдёт о том, что же предшествовало выбору профессии.

Последнее время я слышу множество разговоров о разработке, основанной на тестировании (TDD), о разработке, основанной на функционировании (BDD), об экстремальном программировании (XP), о SCRUM-е, о собраниях стоя и ещё Бог знает о каком количестве методик для создания ПО, но все эти методики не имеют смысла, если ПО, которое мы создаём не соответствует требованиям пользователей. Давайте я попробую это объяснить по-другому. Идеальная реализация неправильно составленной спецификации бесполезна. Так же, как и полезность прекрасно написанной библиотеки стремится к нулю, если у неё нет документации. Что-то определённо не так, если ваше приложение не решает поставленную проблему или, если никто не знает как им воспользоваться.

Здорово. И как же нам решить эту проблему? Проще, чем вы думаете, и достаточно важно, чтобы выделить ответ в отдельный параграф.

Первым делом создайте Readme файл.

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

Часто можно услышать мнение, что в России аутсорсинг не прижился и является столь же редким явлением, как и амурские тигры. Причин называется много: и боязнь «слить» свою информацию малоизвестным третьим лицам, и малое предложение таких услуг (как следствие – высокая цена), и недостаточно высокое качество. Среди причин часто упоминают невозможность наорать матом на находящегося на аутсорсинге исполнителя и заставить его работать сверхурочно до 23 часов без доплаты, только потому, что «так надо». То же и с безопасностью – «своего» сотрудника может припугнуть собственная служба безопасности так, что он не только сам не продаст никакой информации конкуренту, но и сдаст в СБ своих коллег, которые уже это сделали.

Для чего

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

Намба 0: Вступление

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

Как раз в этот момент я хотел подучить программирование и искал несложную задачу. Сайт я накидал довольно быстро — за пару вечеров, рассказал о нем коллегам по работе и паре знакомых в IRC, и собирался уже о нем забыть, как вдруг обнаружил, что за два дня сайт посетило 500 человек, из которых чуть ли не треть подписалась на RSS. Стало понятно, что концепция людям понравилась. Немного прилизав сайт внешне, я решился показать его Хабрасообществу — Шортики — короткие и смешные, прошу любить и жаловать.

P.S. Учитывая то, что это не совсем стартап (проект пока некоммерческий, да и «стартап» — слишком громкое слово для моей поделки), приобретенная за годы пребывания на сайте хабрасовесть не позволила мне написать нетехническую статью. Поэтому, под катом вас ждет занимательная история о том, как мы готовили Шортики к Хабраэффекту.

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

С версии 0.8.46 в nginx появились опции, позволяющие легко и просто настроить прозрачное кэширование для анонимных пользователей.

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

Не секрет, что пользователи любят, когда контент на сайте обновляется чаще, чем раз в год. Эту любовь пользователей к динамическим страничкам разделяют и поисковики. Google, например, умеет определять наличие обновляющихся блоков на страничке и добавляет ей немного кармы (читай, PR).

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

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

Disclaimer: эта и дальнейшие статьи серии написаны двумя хабраобитателями: honeyman — программистом стартапов, в свободное время экспериментирующим с торговлей на бирже и созданием аналитического софта для этого, в сотрудничестве с kaichik — журналистом и главредом автомобильных проектов. Если вы в предыдущем предложении не заметили слов «финансист», «лицензированные консультативные экономические услуги» и «богатый опыт» — то наверное, это потому, что их там не может быть.

• Часть I: акции, мажоритарии, контроль над компанией.
• Часть II: стоимость акций, биржа, самый лучший способ торговать картошкой, и кого же можно встретить на рынке бирже.
• Часть III: процесс IPO, его польза для компании, основателей и владельцев, а также почему у руководства компании при открытии торгов такой замученный вид.
• Часть IV: влияние IPO на доход от адулт-партнёрок.
• Часть V: жизнь после IPO.
• Часть VI: сложности выбора — два Lamborghini Gallardo или один Aventador?
• Часть VII: про инсайд.
• Часть VIII: о мотивации.

Итак, часть I: акции, мажоритарии, контроль над компанией.

Что такое акции, и для чего они нужны?

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

Изучая кодировки, я понял, что недостаточно хорошо понимаю системы счислений. Тем не менее, часто использовал 2-, 8-, 10-, 16-ю системы, переводил одну в другую, но делалось все на “автомате”. Прочитав множество публикаций, я был удивлен отсутствием единой, написанной простым языком, статьи по столь базовому материалу. Именно поэтому решил написать свою, в которой постарался доступно и по порядку изложить основы систем счисления.

Введение

Система счисления — это способ записи (представления) чисел.

Что под этим подразумевается? Например, вы видите перед собой несколько деревьев. Ваша задача — их посчитать. Для этого можно — загибать пальцы, делать зарубки на камне (одно дерево — один палец\зарубка) или сопоставить 10 деревьям какой-нибудь предмет, например, камень, а единичному экземпляру — палочку и выкладывать их на землю по мере подсчета. В первом случае число представляется, как строка из загнутых пальцев или зарубок, во втором — композиция камней и палочек, где слева — камни, а справа — палочки

Системы счисления подразделяются на позиционные и непозиционные, а позиционные, в свою очередь, — на однородные и смешанные.