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

Для того чтобы наказать говнокодеров облегчить страдания тех, кто делает ревью кода, можно использовать автоматические средства проверки кода, которые всем давно известны. Это PEAR и PHP Code Sniffer.

Ура! Еще один, свеженький… чем он лучше других?



а) Новенький! Всегда, кто берется что-то делать, то обычно смотрит: есть ли в этом смысл, и если есть — делает это.
б) Красивенький! Можно не точить, а ставить из коробки. Основан на Bootstrap'е и иконках Glyphicons
в) Само собой мультиселект файлов, Drag&drop, прогрессбар и превьюшки фотографий.
г) Поддержка кросдоменного соединения, докачка и ресайз фоток на стороне клиента.
д) Готов для любой платформы сервера (PHP, Python, Ruby on Rails, Java, Node.js, и тому подобное.)

blueimp.github.com/jQuery-File-Upload

Поддержка браузеров:

github.com/blueimp/jQuery-File-Upload/wiki/Browser-support

Лет 6 назад, в мою бытность сисадмином в одной конторе, мне приходилось обслуживать несколько серверов на FreeBSD — прокси, почтовик, web-сервер, ftp, ipfw, в общем, все как у всех. Работало все на двух физических серверах, и было у меня желание заиметь какую-нибудь универсальную графическую оболочку для удобства управления всем этим хозяйством. Ну и, конечно же, таковой нигде не было. Были попытки разных умельцев создать свои GUI для управления подсистемами по отдельности: один для squid, другой для sendmail и т. д. Конечно, можно было какую-то часть управления выполнять и в webmin, но это не доставляло никакого удовольствия. Как говорили мне — неправильно работать с *nix-системами через GUI. Нет, естественно работа в командной строке не доставляла неудобства, но хотелось чего-то более универсального. В итоге, я написал несколько скриптов, которые вызывали псевдографику на черном экране, где можно было добавлять/удалять правила, рулить пользователями и т. д., на чем как-то все остановилось, хотя интерес к удобству управления через GUI и не пропал.

Мне от моноширинных шрифтов многого не надо. Адекватная поддержка кириллицы. Для программирования — отсутствие замыливания. Возможность различать 0 (который ноль) и О. Возможность различать I (которое i), l (которое L) и | (которое or). Для работы в консольном двухпанельнике — поддержка псевдографики. Однако в современном мире подобных шрифтов не так, чтобы много. Откуда же их взять?

Осторожно! Под катом — сплошные анахронизмы.

У каждой задачи есть несколько вариантов решения. И иногда в угоду скорости приходится выбирать не самый красивый, зато работающий и выполняющий поставленные перед ним цели. Итак, в один не очень прекрасный день возникла необходимость реализовать следующую функцию: у каждой (почти) страницы сайта должны быть автоматически сгенерированные копии в форматах DOC и PDF. С сохранением всех таблиц и картинок внутри контента. И если с PDF всё относительно просто (tcpdf наш друг и брат), то с DOC'ом возникла морока. Под катом — пример решения данной задачи.

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

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

Теперь давайте посмотрим, как поступит в этом случае типичный джуниор. Есть задача – её надо решить. Их так учили в университетах. Многие из них ещё находятся под влиянием маргинального лозунга «пиши код, б##дь!». Итак, он наливает себе растворимого кофе, надевает наушники с чем-нибудь пожёстче и погромче и уходит в поток на пару-тройку часов.

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

Привет!

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

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

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

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

Вот одна из распространённых проблем многопоточных(concurrent) систем: события возникают постоянно в разных частях программы в разное время, и у вас нет возможности контролировать причину и время их возникновения. Чтобы отследить проблему, мы зачастую можем воспользоваться диаграммой последовательностей. Например, такой (спасибо Wikipedia):



Предназначение данной диаграммы — показать взаимодействие между различными параллельными компонентами системы. В данном примере Fred, Bob, Hank и Renee в ресторане. Каждый может легко нарисовать подобную диаграмму на бумаге. Проблема в том, что наброски на бумаге могут отличаться от того, что происходит во время выполнения вашей программы.

Правда было бы здорово, если бы вы могли строить похожие диаграммы на основе данных трассировки программы автоматически? Что ж, Erlang вам в этом поможет.

Добрый день.

Просматривая недавно чужой код, наткнулся на довольно интересную задачу о IQueryable и Expession trees. Надеюсь, решение будет кому-нибудь полезно.

Задача заключается в том, чтобы повторно использовать некоторый Expression внутри другого Expression, например, у нас есть некий f:

Expression<Func<int, int, int>> f = (a, b) => a + b;

И мы бы хотели использовать этот f внтури другого expression, например так:

Expression<Func<int, int, int, int>> g = (a, b, c) => f(a+b,b)*c;

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

5 октября ноутбукам ThinkPad исполнилось 19 лет. Именно в этот день в 1992 году был выпущен ноутбук IBM ThinkPad 700C — топовая модель с 25-мегагерцевым 486-м процессором и цветным TFT-дисплеем. Ноутбуки в те времена рекламировались в печатных СМИ, еще не было официального веб-сайта компании, где можно было бы скачать драйверы и инструкцию, а основной операционной системой был пятый MS-DOS.

С тех пор многое изменилось и аналогичный 10-дюймовый дисплей теперь можно найти в 750-граммовом ThinkPad Tablet. Радикально изменились вес, цена и многократно повысилась производительность мобильных компьютеров. Но кое-что осталось неизменным. Серию ThinkPad делают те же люди в той же исследовательской лаборатории. Уже самый первый ThinkPad имел невероятно удобную клавиатуру, тот самый красный TrackPoint, отлично заменявший в походных условиях мышь и еще не изобретенный тачпад, и множество возможностей для апгрейда. В этой статье — фото первого ThinkPad и некоторых других «архивных» моделей.

Преамбула

Наверное, у каждого из нас дома немало цифровых медиа-устройств, общающихся по WiFi или подключённых к сети с помощью обычной витой пары. У меня, к примеру — КПК, нетбук, пара ноутбуков, пара компьютеров и ещё пара смартфонов. Последние (парочка Nokia 5800 Xpress Music), благодаря тому, что даже в ванной или в постели постоянно находятся под рукой, оказались самыми часто используемыми девайсами. Благо и серфинг, и общение через GTalk/Skype, и простенькие игрушки-убийцы времени — всё доступно. Вот только памяти у девайсов всего по 8 Гб, так что фильмов туда не шибко накидаешь, да и конвертировать, а потом заливать на смартфон каждый фильм — на это нужно время, а ведь есть ещё такая штука, как лень! Одним словом, захотелось иметь возможность как-то просматривать медиаконтент (и в первую очередь — видео) с домашнего сервера в любой момент, не конвертируя и не совершая лишних телодвижений.

Если и есть что-то, что веб-разработчики любят, так это знать что-то, что лучше традиционного. Но традиционное является таковым по одной причине: это дерьмо работает. Что-то давно беспокоило меня во всей этой шумихе вокруг Node.js, но у меня не было времени разобраться, что именно, пока я не прочитал полный боли в жопе пост от Райана Дала, создателя Node.js. Я бы забыл его, как любое очередное нытьё какого-то осла о том, что Unix слишком сложен. Но, как полицейскому, который, жопой чуя, что что-то не так с этой семьёй в микроавтобусе, останавливает его и находит пятьдесят килограммов героина, мне показалось, что что-то не так с этой слезливой историей, и возможно, просто возможно, он понятия не имеет, что делает, и много лет программирует, никем не контролируемый.

Вступление

48 часов в пути, а то и больше, многие даже не знают, как можно провести столько времени за рулем. Они, конечно, догадываются, что существуют такие профессии как водитель грузовика – дальнобойщик, но, смею предположить, даже не думали о том, что такое долгая дорога и как проводить время за рулем.
Я люблю путешествовать и люблю свой мотоцикл. Было время, когда я мог за сутки преодолевать до 1000 км. Это очень много, даже для такой страны как Россия.

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

Именно о решении, которое позволяет отслеживать транспортные средства в реальном времени мы и поговорим сегодня.

Принудительное приведение типов в Erlang

Erlang — во многом уникальный язык. Я начал его изучать недавно, и, хотя имею более десяти лет опыта в программировании, он продолжает меня удивлять своей гибкостью и удобством в различных моментах.
Но есть одно большое «НО», которое отсутствует в Erlang — это автоматическое приведение типов. Как человек, развращенный неявным приведением типов в большинстве современных языков программирования, я набросал модуль, который позволяет не задумываться о типе исходных данных.
В процессе написания собственной CMS на базе Erlang я постоянно пользуюсь им и рекомендую его для других программистов на Erlang.

Аббревиатура OFDM расшифровывается как Orthogonal frequency-division multiplexing. В русскоязычной литературе встречается несколько различных переводов, несущих, в принципе, один смысл: OFDM — это механизм мультиплексирования (уплотнения) посредством ортогональных поднесущих.

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

Иллюстраций: 18, символов: 27 399, строк кода: 99.

Решил поделиться накопленным за 8 лет опытом в с сфере разработки, внедрения и сопровождения автоматизированных систем уровня предприятия. Речь не пойдет про контроллеры и АСУТП или про ERP с бухгалтерскими делами, а расскажу про то как мы делаем то что между ними, где уже нет датчиков, но еще нет и денег, а есть заготовки, полуфабрикаты, изделия, станки, технологи, плановики и отчеты.
Кому интересна эта тема добро пожаловать…

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

Проблема в том, что никто не знает, как на самом деле писать классный софт быстро и правильно. Waterfall благополучно скончался на рубеже веков, а новые методы разработки (agile) пока не могут решить фундаментальные проблемы.

Введение

В замечательной статье с trapexit «Building a Non-blocking TCP server using OTP principles» рассказывается, как построить неблокирующий TCP сервер используя принципы OTP. Думаю, каждый, кто начинал изучать elrlang рано или поздно сталкивался с этой статьей. Для построения неблокирующего TCP сервера в указанной выше статье используется недокументированный функционал из модуля prim_inet.

Не буду филосовствовать хорошо или плохо использовать undocumented features, в некоторых «костыльных» решениях это действительно нужно, в продакшене я бы предпочел использовать проверенные средства. На заметку, даже в самой статье автор предупреждает: "Examining prim_inet module reveals an interesting fact that the actual call to inet driver to accept a client socket is asynchronous. While this is a non-documented property, which means that the OTP team is free to change this implementation, we will exploit this functionality in the construction of our server [1]."

В данной статье изложены размышления и фантазии на тему «как можно было бы скрестить Erlang и PHP, чтобы случилось вселенское счастье», а не описание готовой технологии или продукта. Впрочем, мы намерены это реализовать, скорее всего, в форме open-source проекта, если, конечно, уважаемая хабра-аудитория не отговорит :) Собственно, одна из главных задач этой статьи — понять, насколько идея интересна и потенциально полезна широкому PHP-сообществу. Кстати, некоторые из проблем, обсуждаемых в статье, справедливы и для других популярных скриптовых языков (тут я подразумеваю Ruby и Python), так что предлагаемое решение, возможно, будет актуально и для них.