0x00 Предисловие

В детстве мы смотрели фильмы Хакеры, Взлом, Пароль Рыба-меч, и прочие творения голливуда. Не смотря на юный возраст, вдохновившись мы искали информацию о хакинге, фрикинге везде где только было возможно. Помню тогда еще компакт-диски ходили с наборами выжимок с разных эхо-конференций. Осваивали программирование, постигали устройство IP-сетей, операционок и всяких железяк. Игры в промышленный шпионаж и прочие прелести детства. Мечта украсть миллион и желательно баксов с помощью компютеров прочно сидела в наших головах. Но… детство проходит, школа заканчивается, попытки собственного бизнеса, работа в различных телекоммуникационных компаниях, и вот уже желание своровать сформировалось в желание построить честный высокотехнологичный бизнес, что оказалось сложнее, и следовательно интересней. Однако, не зря говорят, возможность украсть создает преступника.

Я когда-то работал в компании, где нельзя было говорить о своей зарплате под страхом… я даже не знаю чего. Как дети испытывают ужас от того, что “взрослые заругают”, так и мы боялись ей делиться. О том, какая кара нас ожидает, приходилось только догадываться.

Ад в представлении Босха.

И все равно все все знали. Почему? Потому что чтобы закон работал, за ним должна стоять идея, которую разделяет большинство. Какая идея стояла за этим законом? Идея скрыть несправедливую оплату труда. Ведь если она справедливая, то зачем скрывать?

Я рад приветствовать вас, дорогие читатели.

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

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

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

Но прежде чем вступать на путь взращивания из себя старшего разработчика, нужно задать себе простой вопрос: «А мне нравится программировать?».


Старший разработчик. Взято отсюда.

Сегодня вышел Erlang плагин для IntelliJ IDEA.
Он бесплатен, доступен как в Community Edition, так и в родственных продуктах: RubyMine, PyCharm, WebStorm и т.д.

Основные возможности

• Подсветка синтаксиса
• Автодополнение имен функций, переменных, записей и ключевых слов
• Поиск по коду для функций, модулей, переменных и записей
• Базовые рефакторинги: rename и safe delete
• Навигация по коду: structure view и go to declaration
• Просмотр докумендации для функций и модулей (edoc формат)
• Базовый форматтер
• Подсветка unresoved переменных и записей

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

Читая статью об устройстве на работу в ABBYY, встретил в ней упоминание задачи:

быстро – за O( log N ) арифметических операций над числами – найти N-е число Фибоначчи

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

Идея

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

Да не простую мне хотелось табличку, а фичастую, чтобы она умела:

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

И вот как я это сделал…

Автор: Джоэль Спольски. Оригинал.

Статья посвящена оверинженирингу и тем, кто предпочитает старые костыльные решения лишь потому, что они очень просты. Перевод под катом.

Споры о том, что лучше: ручное управление или автоматическое ведутся во многих областях науки и техники. Положиться на человека или отдаться на откуп бесстрастным механизмам и алгоритмам? Похоже, что в мире создания Enterprise решений чаша весов склонилась все-таки в сторону автоматического управления памятью, большей частью из-за того, что возиться с указателями, ручным управлением памятью и закрашивать седину после каждого бага, появившегося из-за «неправильного» компилятора С/C++ не хочется сейчас уже никому. Но до сих пор возникают на форумах топики, где не сдающиеся суровые приверженцы ручного управления памятью яростно и непримиримо отстаивают свои ретроградные взгляды в борьбе с прогрессивной частью человечества. Пусть их, оставим их в покое.

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

Файлы здесь.

Автор: Эндже Альбертини (Ange Albertini)
Перевод на русский: Lyr1k

Вот смотрю как товарищ grokru выложил свое творчество и прямо вдохновляюсь. И поскольку мне было скучно, я решил тоже вспомнить былое и наштампить иконок. Заняло все это порядка 18-20 минут.



Попробовал себя в народном творчестве так сказать. Может совместно создадим habrapack?

Архив с .PSD и .PNG

Признак того, что объект не должен быть классом — если в нём всего 2 метода, и один из них — инициализация, __init__. Каждый раз видя это, подумайте: «наверное, мне нужна просто одна функция».

Каждый раз когда из написанного класса вы создаёте всего один экземпляр, используете только раз и тут же выбрасываете, следует думать: «ой, надо бы это отрефакторить! Можно сделать проще, намного проще!»

Перевод доклада Джэка Дидриха, одного из ключевых разработчиков языка Питон. Доклад прозвучал 9 марта 2012 на конференции PyCon US.

На прошлой неделе состоялся успешный эксперимент по запуску нового решения для download-сервиса. Один достаточно скромный сервер (2 x Intel Xeon E5620, 64 GB RAM) под управлением Java-приложения собственной разработки принял на себя нагрузку восьми Tomcat'ов, обслуживая более 70 тысяч HTTP-запросов в секунду общей пропускной способностью 3000 Mb/s. Таким образом, весь трафик Одноклассников, связанный с пользовательскими смайликами, обрабатывался одним сервером.

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

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

Sublime Text 2 — это платный текстовый редактор, написанный на C++, который:

• Работает в Linux, OS X и Windows
• Обладает приличной скоростью работы
• Приятным интерфейсом (включая всевозможные анимации)
• Гибко настраиваем (правда, не в GUI, а в json-конфигах)
• Имеет множество плагинов, число которых растёт как на дрожжах
• Поддерживает VIM-режим
• Использует fuzzy-поиск

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

С ростом популярности Erlang часто стали задавать вопрос «— А Erlang — объектно-ориентированный?». Правильный ответ был бы «— Да что вы, нет!». Но мы не могли так заявлять в полный голос, поэтому пришлось выкручиваться. Мы придумали несколько достаточно нетривиальных ответов, которые бы представляли Erlang типа-объектно-ориентированным языком (для тех, кто больше всего тянет руку с этим вопросом), но при этом и не объектно-ориентированным для тех, кто на самом деле в теме.

Вступление

Тернист и извилист путь Java-платформы к правильному способу записи строчек в лог-файлы. История logging в Java довольно познавательна в плане изучения особенностей Open Source, в том числе его взаимодействия с корпорациями и единичными программистами. Я собираюсь рассказать столько, сколько возможно, об истории развития Java logging, а также о том, к чему все пришло и как жить дальше.

Я не умею программировать на объектно-ориентированных языках. Не научился. После 5 лет промышленного программирования на Java я всё ещё не знаю, как создать хорошую систему в объектно-ориентированном стиле. Просто не понимаю.

Я пытался научиться, честно. Я изучал паттерны, читал код open source проектов, пытался строить в голове стройные концепции, но так и не понял принципы создания качественных объектно-ориентированных программ. Возможно кто-то другой их понял, но не я.

И вот несколько вещей, которые вызывают у меня непонимание.

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

Повторное использование функций

В JavaScript каждый объект ссылается на объект-прототип, из которого он может наследовать свойства. Прототипы — отличные инструменты для повторного использования кода: один экземпляр прототипа может определять свойства бесконечного числа зависимых сущностей. Прототипы могут так же наследоваться от других прототипов, формируя, таким образом, цепочки прототипов, которые более-менее повторяют иерархии наследования «классовых» языков типа Java and C++. Многоэтажные иерархии наследования иногда бывают полезны при описании природного порядка вещей, но, если первичным мотивом служит повторное использование кода, такие иерархии могут быстро стать искривленными лабиринтами бессмысленных субклассов, утомительных избыточностей и неуправлямой логики («кнопка — это прямоугольник или контрол? Вот что, давайте унаследуем Button от Rectangle, а Rectangle может наследоваться от Control… так, стоп…»).

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

Немного истории

Я являюсь студентом уже 4 курса математического факультета, и до того как я начал заниматься программированием, я считал себя математиком на 100 процентов.

В конце первого курса мой преподаватель по информатике, который занимается олимпиадным программированием, обратил на меня внимание. Им как раз не хватало одного математика в команду. Так потихоньку меня начали приучать к олимпиадному программированию. Скажу честно, для меня это было очень сложно: для человека, который узнал слово Delphi на первом курсе. Однако мой преподаватель оказался очень грамотным специалистом и нашел хороший подход ко мне. Он начал давать мне математические задачи, который я сначала решал чисто математически, а уже потом писал код (с грехом пополам).

Мне очень нравится подход моего преподавателя: «разберись с этой темой, а потом расскажи нам, да так чтоб мы все поняли».

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

Я помню, как долго мучился с этими задачами, чтобы они прошли все тесты на сайте informatics.mccme. Зато теперь я очень рад, что прошел через все испытания и знаю, что же такое задачи вычислительной геометрии.

_{Томпсон (сидит) и Ритчи работают на PDP-11, 1972 год.}

Период 1968-69 гг. был очень неопределенным для Bell Labs: проект операционной системы с разделением времени Multics (Multiplexed Information and Computing Service), разрабатываемой с 1964 года для дорогой 36-битной ЭВМ GE-645, не имел четких перспектив и целей, а лишь разрастался в размерах и сложности, всё ясней был виден его предполагаемый провал. В конце концов, American Telephone & Telegraph вышла из проекта, в который за пять лет были вложены миллионы долларов.

Однако, некоторые из инженеров, работавших над Multics — Кен Томпсон, Деннис Ритчи, Малкольм Дуглас Макилрой, Джозеф Оссанна, — ощущали необходимость в продолжении работы над подобным проектом, и не хотели терять успевшую сформироваться уютную рабочую атмосферу. Поэтому в 1969 году они начали искать альтернативу Multics: Оссанна, Томпсон, Ритчи пытались протолкнуть покупку машины средней мощности, для которой группа обещала написать операционную систему. Заказ на предлагаемые ЭВМ DEC PDP-10 и Sigma 7 так и не был сделан, и хотя несколько раз ситуация выходила на грань получения нужного оборудования, было вполне очевидно, что команда просит слишком крупную сумму для проекта с расплывчатым планом, тем более, что после провала Multics операционные системы стали не настолько привлекательной сферой. Поэтому Томпсон (в основном это была его задумка), Кэнэдэй и Ритчи (привнесший идею файлов-устройств) разработали на обычных черных учебных досках и бумаге устройство файловой системы, которая позже стала сердцем Unix.