Это красноречивое объявление я увидел и сфотографировал в подъезде своего знакомого на двери неизвестного мне товарища. Возможно, стоило позвонить в дверь и познакомиться, но я растерялся и этого не сделал. Если товарищ есть на Хабре, то ему — большой привет.

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

На этом печальная рефлексия закончена, ведь вы читаете позитивный воскресный пост.

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

Ещё больше способов, наверняка, предложат в комментариях.

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

Введение

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

Обойдусь без копипастов и даже ссылок о том, что Ruby за зверь такой, ибо написано было уже сполна. В данном посте просто хочу рассказать о пути изучения Ruby (и, впоследствии фреймворка Ruby on Rails) человека далекого от программирования.

1. Любопытство

«Насколько далекого?», спросите вы, а я отвечу — «Чуть менее, чем полностью», так как в десятом классе в школе у меня были уроки программирования, парочка из которых были уделены Паскалю. Признаюсь, впоследствии о html узнал, и даже мог в Dreamweaver-e сверстать страничку или поставить готовый движок, да по инструкции налепить плагинов, но не более.
Хотя компьютеры мне нравились, пошел я учиться на экономиста* — бакалавриат, магистратура по бух. учету и аудиту, аспирантура по финансам, работа в банке, преподавание, страхование. Но не жилось мне спокойно в финансах, — финансовый калькулятор удовлетворял необходимости решения тривиальных задач, но не удовлетворял мой мозг. А ему хотелось посчитать не только будущую и приведенную стоимость актива, но и создать массив данных из исторических стоимостей этого актива за n лет, высчитать среднюю доходность, дисперсию и, в конце-концов построить красивый график!

Проблемы контроля версий баз данных и миграций между версиями уже не раз поднимались как на Хабре (1, 2, 3 и др.), так и в Интернете (преимущественно, англоязычном).

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

За последнюю неделю появилось несколько топиков с названием «10 однострочников на <MY_LANGUAGE>, которые произведут впечатление на ваших друзей», которые содержат однострочное решение нескольких простых задач, демонстрирующее достоинства и «крутость» любимого языка программирования автора. Я решил перевести их и для сравнения собрать в одном топике. Вся волна началась (вроде как) со Scala.
Итак, поехали!

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

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

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

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

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

Вы хотите жить эффективно? Устройтесь на работу с полным графиком, поступите в аспирантуру, начните ходить в спортзал и делать зарядку по утрам. Если покажется мало, то возьмитесь за два-три сторонних проекта. Через пару месяцев случится одно из двух: либо вы сдохнете, либо самоорганизуетесь и уже никогда не будете забивать голову ерундой вроде тайм-менеджмента.

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

Но что можно сделать такого интересного на Scala? На самом деле, выбор не слишком большой. Я как-то придумал небольшую тулзу, неспешно написал ее, и «забил». А через несколько месяцев, к своему стыду, гуглил синтаксис «for loop»…

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

Я переписал на Scala и выложил на GitHub парочку примеров. На скрине как раз один из них — MSA Fluids. Заинтересовавшихся прошу под кат.

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



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

Речь пойдёт о далёком 2005 году, когда только-только вышла Civilization4 от Sid Meier. К тому времени я плотно висел в Civilization3, прошёл её раз дцать на самых разных картах, и тут вышла долгожданная четвёрка. Это были годы P3-512Mb для mid-end и P4-1Gb в hi-end. Только топовые конфиги в те годы имели два гига памяти на борту.

Civilization 4 вышла с графикой уровня года 2002-2003го, что в принципе нормально для мэинстрима тех времён, особенно учитывая что это пошаговая стратегия, а не шутер. Но жрала с течением игры до 900Mb оперативки, что приводило к жуткому свопу, особенно на больших картах, особенно к концу игры, особенно на ноутбуках. Народ недоумевал, я тоже. Учитывая, что в те же годы вышел Far Cry с куда более красивой графикой, и который вполне игрался на максимуме даже с 512Mb на борту, такое поведение Civilization 4 выглядело крайне странным. Захотелось разобраться и покарать…

Я хочу рассказать о том, почему в отдельности не работают подходы, которые люди начинают применять, прочитав ту или иную книгу из области time-management или управления финансами.

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

Вот, например, езда на автомобиле. Сначала человек меняет свои привычки, установки, доводит до автоматизма простые действия. Затем сдает экзамен, и только потом выезжает на дорогу и начинает набирать настоящий опыт, в процессе которого и становится мастером.

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

Или с деньгами.

Есть модель мира, и есть реальный мир.
Как в физике — есть какое-то явление, а есть его модели.

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

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

Однако где-то 95% людей не знают, что у них в голове мозг занимается тем же самым, только первые годы жизни. Он изучает и моделирует реальный мир, закладывая себе модели явлений, характеров людей, абстрактных понятий, и так далее, которые потом человек в своем сознании использует как инструмент, воспринимая модель как реальность. Далее всю жизнь человек этим и занимается, составляя все более сложные модели.

Вот только отличий от физиков тут три. Первое — это незнание природы работы мозга. И отсюда вытекающая уверенность, что все, что человек видит, думает и знает — и есть истина. То есть человек себя убедил (читай сделал себе модель) в том, что Windows лучше, чем Linux — все, теперь в его модели мира может быть только этот факт. Второе отличие как раз в уточнении модели. Люди не уточняют модели реальности, как правило, более того, мозг специально отсекает факты, противоречащие модели, либо вырабатывает «адаптеры» в виде «логических объяснений», чтобы не нарушить комфорта в восприятии мира — все знают нелюбовь к изменениям, боязнь, что «мир встанет с ног на голову».

Преамбула.

В связи с бурным развитием мобильных устройств и ОС Google Android в частности, интерес к разработке программного обеспечения под данную платформу весьма закономерное явление. Как оказалось, он мало чем отличается от обычной разработки на Яве под десктоп/веб, а с учетом возможности использования «стандартного» IDE (Eclipse) путем скачки и встраивания SDK Андроида, а также наличия исчерпывающей документации многие технические вопросы снимаются сами собой. Концептуальный аспект (т.е. идея для реализации в виде ПО) также не заставила себя ждать, благо платформа сравнительно новая, не смотря на недавно вышедшую уже версию 2.1, и конкурентная среда соответственно не такая насыщенная, если взять, к примеру, разработку под тот же iPhone. (Тут могла бы быть развернутая часть о самом ПО, но ввиду некоторых нюансов, таких как незаконченность проекта и отсутствие конкретных результатов, пока ее пропустим).
Оставался последний, и, естественно, самый интересный (логично, не правда ли?) вопрос – денежный, а конкретно – как правильно вывести честно заработанные дензнаки, полученные от продажи ПО на Android Market.

Вдаваться подробности не буду, все-таки статья ориентирована на тех, кто примерно ориентируется в данной теме, скажу коротко — в данном случае под прицелом оказывается сервис обработки онлайновых платежей Google Checkout, который с нерезидентами США изначально не работает. Насколько мне известно, прямых путей решения данной проблемы нет, поэтому пришлось искать обходные дорожки.

В вашей системе время играет важную роль? Ваши пользователи/компоненты распределены по территории всего земного шара, или хотя бы нашей необъятной родины? Значит, вам нужны часовые пояса. Что ж, это просто. Самое сложное, что вам придется сделать — не запутаться. Об этом мы с вами и поговорим. Для начала вам нужно научиться правильно думать. Думая правильно, все остальное будет для вас либо самоочевидным, либо достаточно простым.

Начнем с часов. Все мы привыкли определять время, глядя на часы на стене. При работе с часовыми поясами такое время называется Wall clock time. В принципе, ничего плохого в нем нет, только в разных местах земного шара в один и тот же момент времени часы показывают разное время. Если задаться целью, можно придумать алгоритм перевода wall clock time одного часового пояса в wall clock time другого. Обычно надо прибавить/отнять разницу в часах между часовыми поясами, кроме (внимание) моментов перехода на летнее/зимнее время. Вот когда начинается переход, вычисления становятся по-настоящему сложными.

Нам же нужно что-то простое и пуленепробиваемое, как… целое число.

Этот отчет я хотел сделать еще в прошлые выходные, но, как обычно, реальность грубо внесла свои коррективы. На российский финал юбилейных десятых Всемирных Кибер Игр я ехал с простой задачей — фотографировать как можно больше посетителей, чтобы заманить их на корпоративную страницу на FB, на которой мы вели прямую трансляцию с турнира. Однако задачу я выполнил наполовину — в какой-то момент я сорвался и начал снимать все подряд (чего греха таить, девушки-модели сильно отвлекали ;-) ), в результате чего материала накопилось на полноценный отчет (МНОГО ФОТО).

Как известно, пару месяцев назад свет увидела jQuery 1.4, в которой мы можем наблюдать множество новых функций и возможностей. А значит, стало еще больше информации для изучения и запоминания. И не важно, насколько хорошо вы владеете искусством jQuery — запомнить всё в любом случае не удастся. И вот здесь нам на помощь приходят всевозможные сборники документаций и шпаргалки, которые очень полезно держать под рукой и периодически в них заглядывать).

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



Итак, как известно, мозг — важнейший орган нашего тела. Кто-то говорит, что он — самая сложная вещь во вселенной. И незнание некоторых его особенностей может очень плачевно сказать на жизни человека.

Но обо всем по порядку.

Понимание роли мозга

Нет невежества страшнее, чем невежество по отношению к самому себе.

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

Итак, в новостях снова пишут, что кто-то еще умер из-за игромании. Да, опять Корея.

Какого ...? послушайте, я не пытаюсь доказать что видео игры — это героин. Я полностью понимаю, что в данном случае у жертвы было много проблем в жизни. Но, половина из вас знает что World of Warcraft затягивает и что доктора считают игровую зависимость серьёзной проблемой. А вопрос вот в чем: может быть какие-то игры намеренно разрабатывались, чтобы заставлять вас играть в них, даже если вы не получаете от этого удовольствия?

Доброго времени суток, уважаемые хабравчане.

Сегодня я хочу продолжить тему обучения в США, начатую мною довольно давно.

В этой статье я хотел бы перейти от общей информации к более конкретной и начать говорить о процессе непосредственного поступления в Американские ВУЗы на степень бакалавра (undergraduate degree).

Вступление

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

Большинство из нас, включая тебя, %username%, проводит много времени в сидячем положении перед монитором. Многие люди в то же время выполняют физические упражнения и занимаются в спортзале — это решает проблему, но лишь отчасти. Долго сидеть вообще вредно (противоестественно), но неправильно сидеть — на порядок вреднее. Поскольку большинство из нас не могут отказаться от долгих посиделок, мы поговорим о том как же все-таки правильно и удобно сидеть — так чтобы при этом не болели глаза, спина, и руки.