Программирование *

Комментарии в своём коде нужно писать не для себя, а для человека, который этот код увидит впервые. Потому что очень скоро этим человеком станешь ты сам.

В мире есть только 10 категории людей — это те, кто понимает двоичный код и те, кто его не понимает.

С праздником всех, кто понял шутку!

Завтра, 12 сентября, будет День программиста — неофициальный праздник программистов, отмечаемый на 256-й день года. Число 256 (два в восьмой степени) выбрано потому, что это количество чисел, которые можно выразить с помощью одного байта. В високосные годы этот праздник попадает на 12 сентября, в невисокосные — на 13 сентября.

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

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

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

Совсем недавно наткнулся в интернете на забавный "хит-парад" наиболее раздражающих вещей для программиста. Поскольку он был на английском — решил перевести текст и несколько адаптировать к нашим реалиям…

ТОП 10 самых раздражающих факторов для программиста

GRASP — General Responsibility Assignment Software Patterns (основные шаблоны распределения обязанностей в программном обеспечении)

Когда речь заходит о термине «ООП», все непременно подразумевают Объектно-Ориентированное Программирование, но сегодня речь пойдет не о нем. Почти. Сегодня я бы хотел рассказать о принципах Объектно-Ориентированного Проектирования, а в частности о шаблонах GRAPS и области их применения.

Пару-тройку месяцев назад наткнулся на замечательный ресурс Project Euler.

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

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

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

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

Окунемся в историю Форта (Forth). В начале 1970х годов Чарльз Мур занялся разработкой программного обеспечения для микроЭВМ, управляющей работой радиотелескопа. Поскольку программирование на Ассемблере привело к неуправляемости разработки довольно сложной программы, а для использующейся микроЭВМ из-за аппаратных ограничений не было языка высокого уровня, Чарльз Мур приступил к созданию компактного и мощного языка программирования, позволившего с блеском решить поставленные перед ним задачи. Успех нового языка программирования определился тем, что на ограниченных ресурсах устройства была создана быстрая и функциональная программа, позволившая делать намного больше, чем первоначально планировалось в техническом задании.

code_swarm — приложение, которое позволяет визуализировать историю коммитов в приложении. Коммит происходит, когда разработчик вносит изменения в код или документацию, а затем отправляет их в центральное хранилище. Разработчики и файлы отображаются, как движущиеся элементы. Когда разработчик делает коммит, он подсвечивается, также подсвечиваются и файлы, затронутые этим коммитом. Цвет файлов зависит от типа файла (код, документация). Если активность разработчика падает, его отображение тускнеет. Гистограмма внизу показывает историю и активность изменений.

Мне бы хотелось написать что-нибудь про Microsoft Singularity. Это очень клёвая штука, и в IT сегодня все говорят про это. Вот обзор Singularity для тех, кто не хочет читать официальные публикации.

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

Допустим, у нас есть куча фотографий разных размеров, с разным соотношением сторон и сохранённых в разных форматах. В общем, тяжёлый случай. Нам нужно весь этот зоопарк выровнять по размерам, учитывая пропорции, и сохранить в JPEG с заданным качеством. Да, и пусть нам иногда захочется задавать размеры не в пикселях, а процентах. Ну и пусть уже тогда захочется файлы выбирать по маске, типа «C:\images\img_01*.jpg».

Садимся, и калякаем на Script-Fu (доступный по умолчанию в GIMP, язык) свой

Небезызвестный Стив Егге опубликовал стенограмму своего доклада в Стенфордском университете. Он затронул целый ряд вопросов, которые недавно активно обсуждались на Хабре: оптимизация программного кода, «нетрадиционные» языки программирования и др. Кроме того, для тех, кто «в теме», доклад содержит ссылки на интересные публикации по компиляции и методам оптимизации.

Ниже я постарался сделать выжимку из весьма объёмного текста. Местами с намеренно провокационными, в духе Стива, заявлениями.

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

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

Данная статья содержит лишь теорию. Практической будет следующая статья (постараюсь чередовать).

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

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

А также о тех, кто хочет научиться этому искусству. Очень субьективно.

Я горжусь своей профессией, но очень не люблю говорить людям мало сведущим в программировании и в ИТ в частности, кем я работаю.
Люди сходятся во мнении, что программист — это тот, кто связан с компьютерами. На этом сходства заканчиваются. Один думает, что я печатаю бумажки в Ворде, другой то, что ремонтирую компьютеры и прочую периферию. Я это не придумываю. Вот случай произошедший как-то в нашем замечательном военкомате. Узнав род деятельности, прапорщик обрадовался:
— О, а у нас принтер не печатает!
— Какой принтер?
— Ну такой, с лентой.

Не знаю почему, но на эту важнейшую технологию обращают так мало внимания. Я хочу несколько исправить положение, поэтому это — первая статья в цикле «Кодогенерация». При рассмотрении данной темы будет использован язык PHP и БД MySQL, но кодогенерация сама по себе возможна на любом языке и с использованием любой БД, просто на PHP мне будет проще объяснять некоторые важные моменты. Так же я буду обращать внимание на состояние дел в других системах и языках.

Данная статья посвящена одному вопросу: какие проблемы присутствуют в современном программировании.