Небольшое предисловие

Меня всегда интересовала история появлений научных понятий. Перед изучающим новый предмет сначала встает череда безликих определений. Некоторые из них таковыми и остаются, другие привлекают внимание и со временем вырастают в полноценные объекты «картины мира». В качестве недоступного идеала такого стремления можно привести высказывание Литлвуда о Рамануджане:

каждое натуральное число было его лучшим другом

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

Далее будет приведено небольшое исследование подобного рода, объектом которого является понятие регулярного выражения.

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

Продолжение перевода здесь

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

Но в то же время, все мои знакомые преуспевающие разработчики помнят своих наставников, которые научили их тому, что значит быть „ведущим“.

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

Все мы пользуемся профайлерами. Традиционная схема работы с ними такова, что приходится изначально запускать программу «под профайлером» а затем, после окончания ее работы, анализировать сырой дамп с помощью дополнительных утилит.
А что делать если мы не имея root'а хотим запрофилировать уже работающую программу, которая долго работала «как надо», а сейчас что-то пошло не так. И хотим это сделать быстро. Знакомая ситуация?
Тогда рассмотрим наиболее популярные профайлеры и принципы их работы. А затем профайлер, который решает именно указанную задачу.

Введение

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

Так давайте попытаемся написать программу, которую проблематично будет создать на других языках. Как следует из названия статьи, эта программа будет редактировать собственный код по мере своего выполнения. Для ее создания я использую Common Lisp, а точнее его интерпретатор SBCL.

Все чаще приходится слышать: "Работай на результат!"

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

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

"Обязательна ориентированность на результат!" — напишет пожилая кадровичка «ГорАвиаВагонМорСтроя» в требования к кандидату на должность помощника бухгалтера, будучи уверенной в том, что раз все так пишут, то и ей надо.

"Наш девиз — Работа на Результат!" — именно так, с двумя Большими Буквами для большего пафоса пишет на корпоративном сайте очередной говноконторы-однодневки молоденькая девочка-всё-в-одном, гордо именующая себя помощником руководителя по связям с общественностью. И этот самый руководитель, даже не знающий, что секретутка это, оказывается, ни больше ни меньше, целый его помощник, тоже употребит эту фразу на фуршете в городской администрации с целью создать себе рекламу в среде местных бюрократов.

Культ карго. Мало кто из произносящих эту фразу может внятно объяснить, какой смысл в неё вкладывается. Люди верят в неё, как в волшебную формулу, заклинание, они пихают её куда ни попадя, надеясь, что она придаст им уникальность, выделит их из толпы таких же неудачников. Организации, Компании, конторы да и откровенные «шараги» не мыслят себя без этого лозунга. Как же это, «Рога и копыта» работают на результат, а мы, что, хуже?



А хуже ли?

Блог Flying Machine Studios
6 декабря 2012 года
перевод статьи The Unofficial Guide to Rich Hickey's Brain



Частично, мое удовольствие от изучения Clojure возникло благодаря знакомству с мыслями Рича Хики о программировании. У Рича есть свой взгляд на фундаментальные концепции программирования, ясный и последовательный, и я думаю, что каждый программист смог бы выиграть, используя его. Каждый раз, когда я смотрю одно из его выступлений, у меня складывается ощущение, что кто-то взял и привел мой ум в порядок.

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

Весь последующий текст основан на выступлении Рича Хики «Are we there yet?»

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

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

Rebase — один из двух способов объединить изменения, сделанные в одной ветке, с другой веткой. Начинающие и даже опытные пользователи git иногда испытывают нежелание пользоваться ей, так как не видят смысла осваивать еще один способ объединять изменения, когда уже и так прекрасно владеют операцией merge. В этой статье я бы хотел подробно разобрать теорию и практику использования rebase.

Теория

Итак, освежим теоретические знания о том, что же такое rebase. Для начала вкратце — у вас есть две ветки — master и feature, обе локальные, feature была создана от master в состоянии A и содержит в себе коммиты C, D и E. В ветку master после отделения от нее ветки feature был сделан 1 коммит B.

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

В пятничном номере NY Times опубликована статья о значительных успехах, который демонстрируют в последние годы разработчики алгоритмов для самообучаемых нейросетей. В глубоких структурах есть несколько скрытых слоёв, которые традиционно тяжело было обучать. Но всё изменилось с использованием стека из машин Больцмана (RBM) для предварительной тренировки. После этого можно удобно перенастраивать веса, применяя метод обратного распространения ошибки (backpropagation). Плюс появление быстрых GPU — всё это привело к существенному прогрессу, который мы наблюдаем в последние годы.

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

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

Выбор темы

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

Приветствую всех пользователей Хабрахабр!
Я недавно начал изучать Haskell, и, немного освоив его, решил поделиться небольшим накопленным опытом. Конечно же, знания Haskell у меня не на таком уровне как у Darkus, поэтому две задачи, которые описаны ниже, ориентированны больше на новичков, но опытные пользователи возможно и поправят, и подскажут как лучше сделать. Эта не только моя первая статья на Хабрахабр, но и вообще мой первый туториал, который я когда-либо писал.

Первая часть короткого и жесткого введения в Haskell. Вторую часть можно найти здесь

tl;dr: Очень краткое и сжатое введение в Haskell.

• Введение
  
  • Установка
  • Без паники
  • Самые основы Haskell
    
    • Объявление функций
    • Пример использование типов
    
    
  
  
• Необходимый минимум из Haskell
  
  • Выражения
    
    • Арифметические
    • Логические
    • Возведение в степень
    • Списки
    • Строки
    • Кортежи
    • Разбираемся со скобками
    
    
  • Полезные вещи для записи функций
  
  
• Сложная часть
  
  • Функциональный стиль
    
    • Функции высшего порядка
    
    
  • Типы
    
    • Вывод типов
    • Создание новых типов
    • Рекурсивные типы
    • Деревья
    
    
  • Бесконечные структуры
  
  

UPD. Если туториал вам понравился, черкните пару строк автору оригинальной статьи. Человеку будет приятно ;)

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

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

Вот так выглядит 700:


По расположению точек несложно заметить, что всего их здесь 7*5*5*2*2.

Далее описание того, как это работает.

При использовании средств параллельных вычислений весьма вероятно может сложиться ситуация, когда алгоритм содержит два таких последовательных этапа: i) каждый j-ый поток сохраняет некоторый промежуточный результат вычисления в j-ой ячейке памяти, а, затем, ii) этот поток должен использовать результаты одного или более «соседних» потоков. Очевидно, что необходимо организовать в коде программы некий барьер по времени, который каждым потоком преодолевается уже после того, как все сохранят свои промежуточные результаты в соответствующих ячейках памяти (этап (i)). В противном случае, какой-то поток может перейти к этапу (ii), пока какие-то другие потоки еще не завершили этап (i). Как это ни прискорбно, но создатели CUDA посчитали, что такой специальный встроенный механизм синхронизации любого числа потоков на одном GPU не нужен. Так как же можно бороться с этой напастью? Хотя Google, судя по подсказкам, и знаком с данным вопросом, но готового удовлетворительного рецепта под свою задачу найти не удалось, а на пути к достижению желаемого результата для новичка (которым я и являюсь) имеются некоторые подводные камни.

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

Собственно, цель достаточно ясна – это позволить гостевой x32 операционной системе использовать помимо «честных» 4Гб оперативной памяти еще какое-то количество, которое можно безболезненно выделить из доступной.

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

Текстовый редактор — это основной инструмент для любого программиста, вот почему вопрос его выбора становится причиной яростных дебатов. Unix традиционно тесно связан с двумя своими многолетними фаворитами, Emacs и Vi, и их современными версиями GNU Emacs и Vim. Эти редакторы имеют очень разный подход к редактированию текста, но при этом сравнимы по мощи.

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

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

Подобные средства есть для всех распространенных настольных ОС, включая Linux и BSD, и многие из них совершенно бесплатны, так что вряд ли имеет смысл ограничивать себя в Блокнотом Windows, nano или cat.

Однако, в среде поклонников Unix гуляет в разнообразных вариациях мем о том, что «Unix — это IDE», в том смысле, что средства, которыми разработчики располагают в терминале, легко реализуют основные возможности современных IDE. Вы можете соглашаться или отказываться признать Unix «IDE» в том самом смысле, что Eclipse или Microsoft Visual Studio. Так или иначе, вас скорее всего удивит, насколько законченную среду разработки может являть собой скромный Bash.