После того, как с классическим (от слова класс) наследованием в JS стало вроде-бы все понятно, я решил разобраться с реализацией другого способа повторного использвоания кода — примесями. Несмотря на довольно непривычное название, способ этот чертовски прост.

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

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

Приветствую!

Я JavaScript разработчик и последнее время занимаюсь разработкой приложений на Ext JS. Для наглядности интерфейсов, иногда необходимо вбить в них JSON данные. Сперва я писал небольшие скрипты на PHP для генерации необходимых данных, но вскоре это стало забирать все больше времени и я отказался от этого подхода. Потом я начал создавать *.json файлы с данными, но зачастую мне требовалось наличие в них полей с уникальным ID и, по возможности, уникальными данными для красоты. Правда, задавать уникальные значения для полей, особенно в массиве из 100+ объектов занятие не благодарное.

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

Я уже достаточно много лет занимаюсь разработкой на java и повидал довольно много чужого кода. Как это не странно, но постоянно от одного проекта к другому я вижу одни и те же проблемы. Этот топик — попытка ликбеза в наиболее часто используемых конструкциях языка. Часть описанного — это довольно банальные вещи, тем не менее, как показывает мой опыт, все эти банальности до сих пор актуальны. Надеюсь, статья пригодится многим java программистам. Итак, поехали:

new vs valueOf

//медленно
Integer i = new Integer(100);
Long l = new Long(100);
String s = new String("A");

//быстро
Integer i = Integer.valueOf(100);
Long l = 100L;//это тоже самое что Long.valueOf(100L);
String s = "A";

Старайтесь всегда использовать метод valueOf вместо конструктора в стандартных классах оболочках примитивных типов, кроме случаев, когда вам нужно конкретно выделить память под новое значение. Это связано с тем, что все они, кроме чисел с плавающей точкой, от Byte до Long имеют кеш. По умолчанию этот кеш содержит значения от -128 до 127. Следовательно, если ваше значение попадает в этот диапазон, то значение вернется из кеша. Значение из кеша достается в 3.5 раза быстрее чем при использовании конструктора + экономия памяти. Помимо этого, наиболее часто используемые значения могут также быть закэшированы компилятором и виртуальной машиной. В случае, если ваше приложение очень часто использует целые типы, можно увеличить кеш для Integer через системное свойство «java.lang.Integer.IntegerCache.high», а так же через параметр виртуальной машины -XX:AutoBoxCacheMax=<size>.

Валидации HTML-форм уделяют очень мало внимания. Например, даже на habrahabr.ru пока я регистрировался и входил на сайт несколько раз мне выдавалось сообщение об ошибке: то код протекции ввел неправильно, то в логине указал email вместо логина. А еще бывает пользователи ошибаются с количеством цифр в номере телефона или реквизитах организации, путают русскую букву «с» с английской, при копировании и вставке в Windows лишнии пробелы добавляются к данным.

Конечно, все это не смертельно. Но было бы крайне удобно, чтобы данные проверялись еще до отправки на сервере. Особенно CAPTCHA, ибо ее часто вводишь с ошибкой.

Для решения данной проблемы были несколько способов: HTML5, jQuery Validate, zForms.ru и еще ряд менее известных библиотек. Но все эти способы имели свои недостатки: HTML5 поддерживается не всеми браузерами и не имеет опции не отправлять незаполненные поля, задать сообщение о несоответствии регулярному выражению, ограничить список допустимых символов для ввода в поле, возможности склеивать поля, посылать значения чекбоксов в формате csv или суммы значений.

Введение

В PHP приложениях отладка при помощи var_dump, debug_backtrace и прочих полезных функций не всегда удобна, и возникает потребность в полноценном отладчике. Эта статья — для тех, кто по каким-либо причинам не хочет использовать IDE, поддерживающие отладку PHP приложений из коробки, вроде NetBeans или PhpStorm, а хочет использовать для этих целей vim, и при этом отладка происходит на удаленном хосте.

Вступление

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

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

Я затвитил эту статью о 5 причинах проводить обзоры кода на CIO.com на прошлой неделе и понял, что на самом деле причин гораздо больше, чем те пять, о которых там написано. Так что к концу дня у меня их было уже больше 20. Это коллекция тех твитов с некоторыми подробностями, описанными здесь.

Причина №1. Достаточно быстрая ответная реакция, чтобы подстегнуть разработчика.
Так как обзор кода производится после кодирования и перед интеграционными и системными тестами, разработчикам не надо ждать столько же, сколько и ответа от отдела по качеству кода (QA). Обеспечив конкретный, своевременный ответ, разработчики могут подстраивать свои навыки кодирования для избежания общих ошибок.

Чем старше я становлюсь, тем менее важной становится запятая. Пусть читатель сам решает, где ему ставить паузы. — Elizabeth Clarkson Zwart

Примерно так я комментировал свой код двадцать лет назад (внимание, чуток драмы):

/*
 * Когда мы дойдем сюда, наша структура уже будет готова. 
 * К тому же, мы создали достаточно большой буфер, в который 
 * можно засунуть все входные данные, плюс есть немного места
 * про запас. Я не уверен, понадобится ли оно, но хуже не будет. 
 * Теперь нам надо обновить счетчик, предполагая, что клиент 
 * уже прочитал значение, но еще не использовал его. Сначала 
 * я хотел переложить обязанность инкремента на плечи вызывающего
 * кода. С другой стороны, это означает, что инкремент нужно делать всем, 
 * поэтому я решил, что будет лучше перенести его сюда. Но мы можем 
 * пересмотреть это решение позже, если вдруг кому-то из внешних функций 
 * захочется делать инкремент самому.
*/
counter++; // инкрементировать счетчик для потребляемого значения

/*
 * Теперь нужно просмотреть весь буфер с данными. Для этой 
 * операции нам понадобится еще один индекс, иначе перед 
 * выходом из функции мы потеряем начальное значение. 
 * Я хотел назвать эту переменную ‘ref’, потому что в некотором
 * смысле мы будем обращаться с ней как со ссылкой на данные. 
 * В конце концов я пришел к выводу, что самым лучшим  
 * названием для нее будет ‘pos’. Если что, я не против обсудить
 * это решение.
*/
char* pos = buffer; // начинаем наш обход данных

/*
Теперь, мы...
*/

Ну что, узнаете? А должны! Если быть предельно невежливым, весь код выше написал нуб. (Между прочим, если вы не знаете, кто такой нуб, значит вы — нуб).

В связи с тем, что на Хабрахабре не нашёл я описания данного простого и в то же время удобного способа создания простых «тултипов» — всплывающих подсказок, я решил о нём написать.
В данном методе не будет использоваться JS, мы довольствуемся лишь CSS3 и HTML5.

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

1. Почему стоит начать работать «в белую»
2. Почему на начальном этапе ИП лучше ООО
3. Что делать, если партнёров несколько

Если вы – начинающий или уже опытный фрилансер и подумываете о работе «в белую», но ещё точно не определились с вопросами «Стоит ли оно того?» и «ИП или ООО?», вэлком

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

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

<?php 

class Images {
	
	public $width;
	
	public $height;
	
	public function SetWidth($value) {
		$this->width = $with;
		return $this;
	}
	
	public function SetHeight($value) {
		$this->height = $value;
		return $this;
	}
	
}

$images = new Images();
$images->SetWidth(100)->SetHeight(100);

?>

Вот небольшой пример. Мы можем в строчку, последовательно, производить действия. Этот же принцип лежит в основе популярной библиотеки jQuery. Да что тут говорить, все современные фреймворки изобилуют подобными конструкциями. А вот что если использовать подобный механизм для построения всего сайта?

Введение

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

Эта статья — не набор “волшебных команд” и рецептов (cookbook, как называют такие наборы по-английски), хотя они тут тоже присутствуют, а, скорее, попытка описать, как общие принципы построения эргономичных интерфейсов можно применить в практике использования Vim, чтобы сделать из него удобную и эффективную среду работы с текстами.

Эта статья также не является tutorial’ом для начинающих пользователей Vim, хотя и им (а также пользователям Emacs) может быть интересна, поскольку некоторые упоминаемые принципы являются достаточно общими и действуют не только в системах редактирования текстов, а вообще везде, где идет речь об использовании компьютера для редактирования чего-либо. Тем не менее, я предполагаю, что читатель знаком с основными концепциями, применяемыми в Vim (режимы, регистры, буфера, команды) и не останавливаюсь на их подробном описании.

По умолчанию Vim настроен очень старомодно, и эта настройка подразумевает, что пользователь при работе с текстом будет мыслить метафорами пятидесятилетней давности, как будто бы сейчас заря эпохи UNIX. Однако дизайн Vim позволяет сделать несколько настроек, после которых система станет выглядеть вполне прилично и станет работать весьма эффективно, сочетая в себе полезные черты и древних юниксовых инструментов работы с текстом, и современных WYSIWIG-процессоров, при этом обходя, насколько это возможно, присущие им недостатки. Вот об этих настройках и приемах их использования и пойдет речь.

Эта статья является переводом цикла из четырёх статей «Linear algebra for game developers», написанных David Rosen и посвящённых линейной алгебре и её применению в разработке игр. С оригинальными статьями можно ознакомиться тут: часть 1, часть 2, часть 3 и часть 4. Я не стал публиковать переводы отдельными топиками, а объединил все статьи в одну. Думаю, что так будет удобнее воспринимать материал и работать с ним. Итак приступим.

На хабре нашел пару упоминаний про эту ORM, да и то давно и в комментариях. Недавно обнаружил, что вышла уже вторая версия. Желающим — вот ссылка на загрузку (GitHub) и на документацию
Цель этой статьи — кратко познакомить читателей с этой ORM-библиотекой.
RedBeanPHP — еще одна ORM-библиотека. Основное ее отличие от коллег, типа Propel или Doctrine, в отсутствии необходимости ручного конфигурирования объектов. Т.е. никаких xml, yml или ini-файлов. RedBenPHP на лету создает таблицы, поля и индексы. Любой объект можно связать с другим. Из БД поддерживаются MySQL, SQLite и Postgres.

Довольно популярная в мире Java парадигма аспектно-ориентированного программирования (АОП) почему-то слабо освещена в разработке на PHP. В данной статье я хочу представить свой подход к написанию АОП приложений с использованием небольшого фреймворка и модуля.

Доброго времени суток!

Желание написать данную статью появилось после прочтения поста Перегрузка C++ операторов, потому что в нём не были раскрыты многие важные темы.

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

Доброго времени суток!
Некоторым программистам иногда приходит в голову мысль «а не изучить ли мне ассемблер?». Ведь на нем пишут самые (с некоторыми оговорками) маленькие и быстрые программы, да и охота ощутить вкус низкоуровневого программирования берет свое. Ну и для общего развития не повредит.
Мысль эта не обошла стороной и меня. Вдохновившись историей одного байта, я ринулся в бой…

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

UPD
В список начали добавляться ресурсы по программингу микроконтроллеров.

Для тех кто в теме, кратко: после осеннего апгрейда Хабра-юзер-стиль слетел — пришлось заново переписать.



Стиль в один клик делает Хабр более уютным и удобным:
— компактная шапка
— меню пользователя на правой стороне (кто ещё помнит, оно изначально было там…)
— уменьшены размеры показателей кармы/рейтинга/индекса — ведь не они главное на Хабре
— заменил появляющиеся точки около комментариев на отступ размером в аватарку + тоненькую линию для определения уровня вложенности
— заменил множественные «ответить» с подчеркиванием штрихами на скромный линк, который появляется при mouse hover
— убрал округленные уголки с аватарок
— если срок голосования за комментарий истек, то показывается только рейтинг, без серых кнопок
— убавил ширину правой колонки (сайдбара)

Кто не в курсе о чем это — предыстория: 1 сезон, 2 сезон.