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

Существует множество причин, из-за которых программист может начать работать над сторонним проектом. Это хороший способ держать руку на пульсе современных технологий, которые сейчас на пике популярности в отрасли. Это может помочь вам отточить свои навыки программирования. И это весело! Ну или должно быть весело.
Но то, что мы привыкли называть “жизнью” может не только усложнить вам завершение проекта, но даже не дать начать работать над ним. Мы часто тратим много времени чтобы придерживаться напряженного графика, и может показаться невозможным использовать хотя бы минутку для личного проекта.
Я начал работать на моим первым сайд-проектом два года назад, и я не эксперт в этом вопросе, чтобы это не значило. Спустя два года, я сделал несколько наблюдений о начале работы над сторонними проектами, которые я начал, почему я смог некоторые закончить, а некоторые нет. То, что я попытаюсь описать не претендует на новаторство, ни на пошаговое руководство, а является исключительно лишь наблюдениями, которые могут оказаться полезными.

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

Одной строкой: тут рекламируется Папирия, онлайновый сервис для подготовки документов в LaTeX. Ходить на papeeria.com.

Введение

Если вы студент, то наверняка либо уже пишете курсовую или диплом, либо всерьез над этим задумываетесь. Если вы к тому же учитесь в техническом вузе и в вашей работе много формул и прочего нетекста, то возможно, вы задумываетесь над тем, в чём его писать — в LibreOffice/Word или в LaTeX. И возможно, от использования LaTeX вас останавливает только то, что Word вот он, под рукой, бери и пиши, а латех надо еще устанавливать, возиться с почти неизбежными подводными камнями и потом еще тупо глядеть на белый лист и думать с чего начать. Вот вам-то мы и хотим помочь. А также тем, кто хочет вести свою научную работу из любого места, где есть интернет.

Для всех остальных: если вы вообще не знаете, что такое латех, то рекомендуем погуглить (можно начать, например, отсюда). Если же что-то знаете и просто хотите потроллить на тему latex vs word, то поищите себе, пожалуйста, другую поляну. Будем премного благодарны.

1. Основы

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

Введение

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

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

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

Зондирование обстановки на Реддите показало, что едва ли хоть кто-то всерьез занимается обработкой изображений на Хаскеле, несмотря на то, что достаточно популярная библиотека Repa предполагает работу с изображениями как одно из основных приложений. Надеюсь, ситуацию сможет изменить библиотека Yarr (документация, гитхаб).

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

GHC (Glasgow Haskell Compiler) — стандартный компилятор Хаскеля. GHC — один из самых крутых компиляторов в мире, но к сожалению без дополнительных телодвижений скомпилированные им программы по скорости больше напоминают интерпретируемые, т. е. работают очень медленно. Однако если раскрыть весь потенциал компилятора, Хаскель приближается по производительности к аналогичному коду на C.

В этой статье я обобщаю опыт выжимания максимума из GHC при создании dataflow-фреймворка Yarr.

Недавно я начал нелёгкое дело по вёрстке диссертационной работы в LaTeX-е. Естественным первым желанием было найти какой-нибудь готовый шаблон. Увы, я не нашёл ничего, что подходило бы под мои нужны. Поэтому я решил сделать свой шаблон (с преамбулой и макрокомандами)! Сразу скажу по поводу соответствия шаблона ВАК-овским требованиям: строгих требований нет (можете сами посмотреть список нормативных документов). Однако определённые требования могут быть у конкретного совета (но они, как правило, весьма похожи и соответствуют здравому смыслу). В своём шаблоне я постарался учесть общие тенденции в оформлении такого рода работ. Не буду приводить кучу технических особенностей вёрстки в LaTeX (на эту тему и так хватает статей), а просто поделюсь готовым результатом: GitHub.

Написание качественной магистерской диссертации полноценно охватывающей все разделы проведенного исследования, основной работы, анализа и апробации результатов является сложной и комплексной задачей, ежедневно с различным успехом решаемой множеством студентов по всему миру. К сожалению, изучение существующей литературы [1, 2], посвященной тематике написания диссертационного исследования, указывает на отсутствие материалов описывающих практический опыт применения различных методов и инструментов, позволяющих не только оптимизировать работу над диссертацией, но и улучшить качество конечного результата.
В данной статье рассмотрим семь практических методов и инструментов, применение которых позволит обеспечить целостное структурирование и систематизацию задач, знаний и различных данных получаемых в ходе работы с диссертацией:

1. Формирование структуры задач.
2. Поиск литературы в каталогах.
3. Сбор, обработка и систематизация информации.
4. Формирование списка литературы.
5. Составление плана по вехам.
6. Определение предмета исследования.
7. «Summary» для научного руководителя.

Обнаруживаю себя вечером в 9 часов на работе, с гневным клиентом в ICQ, которому «срочно надо», и в попытке привести в рабочее состояние код, который сегодня писал другой программист. Похоже, сегодня запустить это не получится. Клиент не стесняется в выражениях, давит на чувство вины. Жутко стыдно. От долгого сидения за компом болят глаза. От необходимости отлаживать и разгребать чужой говнокод — спина. Если у вас болит спина — скорее всего, вы прямо сейчас должны делать работу, которую ненавидите. В голове — отчаянье, злость. И долбит мысль:

Я
Не хочу
Отвечать за чужие косяки

О софистике (софизмах) в дискуссиях и об ООП

Поскольку писать комментарии в режиме «read-only» не положено, снова рискну написать в песочницу.

Вступление

Читая хабр, споткнулся об один из комментариев. Вернее сказать, споткнулся о цитату в этом комментарии:

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

Перед тем, как перейти к сути этой заметки (а точнее — к анализу приведенной цитаты Степанова), также хочу вспомнить небольшую статью с провокационным анонсом («софистика — это математика для жуликов»), которая как-то попалась мне на глаза в глянцевом журнале (что само по себе уже странно; нечасто удается в таких журналах на что-то обратить внимание). Электронная версия здесь. Далее я буду ссылаться на термины из этой статьи, поэтому рекомендую ознакомиться.

Из знакомых мне айтишников очень немногие стараются правильно произносить английские слова. Конечно, привычнее произносить C++ как «си-плюс-плюс», а не «си-плас-плас» или «опен-бэ-эс-дэ», а не «оупэн-би-эс-ди».
Но когда «echo $value;» читают как «ечо валуй» — это уже не смешно. Другой человек вас может просто не понять, особенно иностранец.

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

♫ — прослушать произношение в словаре
► — прослушать произношение на youtube

Начнем с названий:

ABBYY	аби		►
Adobe	эдоуби	[əˈdəʋbɪ]	♫
Apache	эпэчи	[əˈpætʃiː]	►	от «a-patchy»
Asus	офиц. э́сус амер. э́йсус		►
BenQ	бенкью		♫
Cisco	сискоу	[ˈsɪskoʊ]	♫
EBay	ибэй		♫
Eee PC	и писи		►
Ethernet	изэрнэт	[ˈiθərˌnɛt]	♫
Itanium	айтэйниум	[aɪˈteɪniəm]	►
Juniper	джу́нэпэр	[ˈdʒunəpər]	♫
LaTeX	лэйтех лэйтек латех латек	[ˈleɪtɛk] ['leɪtɛx] [ˈlɑːtɛx] [ˈlɑːtɛk]
Linux	офиц. линэкс вар. линукс	[ˈlɪnəks] [ˈlɪnʊks]	►
Mac OS X	мэк оу-эс тэн		►
MySQL	офиц. май-эс-кью-эл вар. май-сиквел		►	как «My Ess Que Ell», см. оф. сайт
nginx	энджин-икс		►	(от engine-x)
PuTTY	пати	[ˈpʌtɪ]		см. оф. сайт
Qt	кьют	[kyut]		см.
TeX	тех тек	[ˈtɛx] [tɛk]		не «текс»
XBox 360	экс-бокс фри сискти		♫
Xen	зен	[ˈzɛn]	♫
Xeon	зион		♫
Xerox	зирокс	[ˈzɪərɒks]	♫
Xilinx	зайлинкс	[ˌzaɪliːŋks]	►
ZyXel	рус. зайксел амер. зайзел		►	см.

Аббревиатуры:

GNU	гну		►	вар. гню
GWT	гвит	[ˈɡwɪt]
ICANN	айкэн		►
IEEE	ай-трипл-и		►	как «I triple E»
ISO	айсо		►
PNG	пинг	[ˈpɪŋ]	♫	как «ping», см. спецификацию
PXE	пикси	[ˈpɪksi]	►
RUP	рап		►
SCSI	скази	['skʌzi]	♫
SOAP	соуп	[soʊp]	►
SQL	эс-кью-эл	[ˈɛsˈkjuˈɛl]		неофиц. «сикуел»
SWF	свиф	[ˈswɪf]		см. спецификацию
WYSIWYG	визивиг	[ˈwɪziˌwɪg]	♫
XAML	зэмл	[ˈzæməl]	►
XUL	зул	[ˈzuːl]
Yii	длинное «и»	[ji:]	►

Обычно аббревиатуры произносятся по правилам английского языка: API — эй-пи-ай, PCMCIA — пи-си-эм-си-ай-эй, OpenBSD — оупен-би-эс-ди и т.д.

Вступление 1.

Много думал и анализировал информацию на тему разработки игр. И чтобы не потерять, а так же поделиться с людьми, получить подсказки, советы и комментарии — решил оформить и выложить статью. На сегодняшний день “геймдизайн” все больше обретает очертания некой науки, требующей особого подхода и изучения. К сожалению, в общем доступе находится очень мало структурированной информации. Что касается иностранных авторов, имеющих большой опыт и ряд успешных проектов — зачастую их труды так и не попадают на прилавки отечественных магазинов. А изучить их в оригинале многим мешает языковой барьер.
В данной ситуации спасением служат статьи, где люди делятся впечатлениям и личным опытом по разработке игр. Эти статьи не только и не столько доносят до читателей новую информацию, сколько подают ее в новом свете, позволяя более четко осознать и отобразить в жизнь.

Вступление 2

Хочу отметить, что на написание материала оказало влияние выступление на Sociality Rocks 2011 Henric Suuronen — руководитель студии Wooga, разработчика Bubble Island и других хитов. Особого внимания заслуживает статья Андрея Плахова “Геймдизайнерам о программистах или как программировать программистов”. По аналогии с той статьей возникла мысль, что программировать можно и пользователей тоже. Программировать их модель поведения, чтобы их развлекать и извлекать нужные нам ценности — платежи, удержание в игре, привлечение новых игроков. И одним из инструментов удержания служит набор функций в приложении, который можно условно назвать игровым циклом. Об этом мы и поговорим далее

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

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

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

Бойтесь Тьюринговской трясины, в которой всё возможно, но ничего конкретного нельзя сделать просто.
Алан Перлис

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