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

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

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

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

Хочу начать вести блог, посвященный метапрограммированию на Ruby.

Demain n'existe pas!

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

Специально ко Дню Защитника Отечества на препарационный стол легли LCD и E-Ink дисплеи, которые, так или иначе, достались мне в несколько побитом жизнью виде.

Как Антон кидал телефон об стену, а также о результатах скрупулёзного разбора дисплеев читайте под катом.

1 Вступление

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

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

Пройдя данный путь до конца, я бы хотел облегчить его тем, кто пойдёт следом и подробно рассказать как это было у нас, на специальности Информационные системы и технологии (230201) кафедры ИС факультета ИТиП СПбГУ ИТМО.

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

• Скачать с Яндекса
• Скачать с Dropbox

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

Привожу перевод статьи Ника Карсона. В статье собраны вместе, как мне кажется, основные правила построения интерфейса для iOS приложений.

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

2. Ориентируйтесь на устройство при создании приложений: учтите не только размер экрана, но и где и когда устройство используется. Больше всего iPad используется для развлечений между 8-11 часами вечера, перед сном, тогда как iPhone — в очереди на автобус или в кофейне. Учтите различные сценарии использования при разработке приложений – включая и то, как далеко устройство расположено от лица пользователя.

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

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

5. При адаптации приложения к экранам различных размеров, помните, что при значительном его изменении – например, от iPhone к iPad – способ использования устройства также изменится. Если размеры ограничены, используйте основные функции приложения, при их увеличении – можно включить любые дополнительные функции, которые не вошли в более сжатую версию, так как у вас появляется возможность обыграть дополнительное пространство.

За остальными 45-ю — добро пожаловать подкат.

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

Дабы облегчить дальнейшее скачивание лекций выкладываю некоторые из ник как торренты.

Преамбула

Здравствуйте. Я являюсь главным разработчиком крупнейшего в СНГ сервера Minecraft (не буду рекламировать, кому надо, те знают). Уже почти год мы пишем свою реализацию сервера, рассчитанную на больше чем 40 человек (мы хотим видеть цифру в 500 хотя бы). Пока всё было удачно, но последнее время система начала упираться в то, что из-за не самой удачной реализации сети (1 поток на ввод, 1 на вывод + 1 на обработку), при 300 игроках онлайн работает более 980 потоков (+ системные), что в сочетании с производительностью дефолтного io Явы даёт огромное падение производительности, и уже при 100 игроках сервер в основном занимается тем, что пишет/читает в/из сети.

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

Здесь я постараюсь расписать серверную часть работы с сетью через Netty, может быть это кому-то будет полезно.

Все о переезде и жизни в TEXAS
Статистика по визам http://www.myvisajobs.com/
Форум http://forum.privet.com/viewforum.php?f=1

Cost-Based Oracle Fundamentals (Expert's Voice in Oracle) / Jonathan Lewis
http://www.amazon.com/Cost-Based-Oracle-Fundamentals-Experts-Voice/dp/1590596366/
http://www.ozon.ru/context/detail/id/2984086/

Контакты:
Michael
zorkus
http://twitter.com/zorkus

golodnyj
G+ http://gplus.to/golodnyj
G+ http://gplus.to/TheArtOfProgramming
podcast@golodnyj.ru

Вчера я опубликовал перевод топика «Прокрастинация разрушила мою жизнь» одного из североамериканских хлопцев с Hacker News. Сегодня вы можете ознакомиться с интересными ответами HN-юзеров.

юзер Isamu

Психолог Пирс Стил в своей книге «Уравнение прокрастинации» считает, что проблема заключается не в перфекционизме, а в импульсивном управлении.
Хотя у вас нет проблем с тем, чтобы начать работу, прокрастинация начинается позже. Вот мой конспект книги:

Предыдущие части:

1. Многокритериальный выбор альтернатив с использованием правил нечеткого вывода. Часть 1/3: Теория
2. Многокритериальный выбор альтернатив с использованием правил нечеткого вывода. Реализация на Java. Часть 2/3: Основной алгоритм

Пример взят из книги: Борисов, Крумберг, Федоров — «Принятие решений на основе нечетких моделей. Примеры использования», 1990. Стр. 94-102

Условие. Руководство института рассматривает кандидатов на замещение вакантной должности на факультете. Задача заключается в том, чтобы, используя описанный выше метод, выявить наилучшеrо из них. Обсуждение среди членов факультета дало следующий результат:
d1: «Если кандидат опытный исследователь, имеет некоторый производственныи стаж и опыт преподавания технических дисциплин, то он удовлетворяющий (отвечающий требованиям)»;

d2: «Если он вдобавок к вышеописанным требованиям может преподавать теорию информационных систем, то он более чем удовлетворяющий»;
d3: «Если он вдобавок к условиям d2 имеет способпость найти заказчика наукоемкой продукции, то он безупречный»;

d4: «Если оп имеет все, oгoвopeннoe в d3, кроме способности преподавать теорию информационных систем, то он очень удовлетворяющий»;
d5: «Если кандидат очень опытный исследователь, имеет способность найти заказчика и хороший преподаватель, но не имеет производственноrо стажа, он все же будет удовлетворяющим»;
d6: «Если он не имеет квалификации исследователя или не имеет проверенной способности к преподаванию, он — неудовлетворяющий».

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

Производители обычно выпускают рекомендации для построения GUI под их OS. Дошла очередь и до Google Android:

Низкий поклон Хабранароду!

Предисловие

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

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

На ХабраХабре наконец-то появился новый блог, посвящённый GTK. Присоединяйтесь! :-)

Привет, %username%!

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

GTK+ — это фреймворк для создания кроссплатформенного графического интерфейса пользователя (GUI). Наряду с Qt он является одной из двух наиболее популярных на сегодняшний день библиотек для X Window System.

Изначально эта библиотека была частью графического редактора GIMP, но позже стала независимой и приобрела популярность. GTK+ — это свободное ПО, распространяемое на условиях GNU LGPL и позволяющее создавать как свободное, так и проприетарное программное обеспечение.

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

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

Прослушав вебинар «How Google Tests Software» я был так вдохновлен, что решил записать некоторые тезисы. Эта статья и есть мой конспект. Прежде всего, я должен внести ясность относительно ее содержания. Это не дословный перевод. Здесь описаны только те вещи, которые показались мне важными. Проще говоря, здесь описано не все, что прозвучало в вебинаре. Так же существует вероятность, что я понял что-то не до конца или даже понял неправильно. Поэтому горячо рекомендую прослушать вебинар самостоятельно.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в Google. Джэймс совместно с коллегами готовится выпустить одноименную книгу. В ней можно будет получить исчерпывающую информацию о том, как проводят тестирование GoogleMaps, Google+, ChromeOS, Android и т.д…