Сергей Протько

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

int decode(int corect_mode, ref int errs, ref long cw)
{
    //остальной код
    //...
    else {
        errs = 0;
        if(parity(cw))
        {
            errs = 1;
            return 0     
        }
        //Остальной код
    }

}

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

Я увы мало работал с серверным JS, но когда разбирался с ним, а точнее выбирал между Erlang и Node.js мне на глаза попалась статья о том, что все в Node.js надо оборачивать в try/catch. Это связано с тем, что если что-то упадет, а ситуации бывают разные, то упадет и весь сервер. А вам это точно радости не прибавит.

jsfiddle.net/g3ZXA/ — увы фишка с first-of-type не сработала. Пример со структурой реализованной как у вас уже дали ранее.

Касательно «слишком много JS» — экономите на спичках. К сожалению у меня не вышло при помощи псевдо селекторов nth-of-type или first-of-type реализовать задуманное. Хотя я считаю что это странно. Если вариант с nth-of-type не катит только потому, что отсчет идет по дереву, то firt-of-type почему не работает, мне не ведомо. Если он аналогичен nth-of-type(1) то смысла в нем я не вижу.

А поместить разделитель в span.item никак?

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

Почему люди переплачивают? При определенных запросах люди экономят. Другое дело что облака нынче в моде, и не всегда выбор облака подкреплен здравым смыслом.

Sony PRS-600. По сути мне ее хватает за глаза, да и последний год как-то реже стал ей пользоваться, как и читать не относящееся к работе. О последнем жалею, но времени нету.
Что касается читалки — сейчас хочу заменить ее на Sony PRS-T1RC, так как из-за сенсорной пленки на моем PRS 600 контрастность ниже чем хотелось бы.
В остальном полностью меня устраивала.

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

Если бы вы написали эти статьи с 3 месяца назад, мне бы они, например, очень пригодились бы.

я использую jplayer и вполне доволен. Хотя как по мне было бы лучше реализовать плеер с возможностью сверстать интерфейс в HTML и JS контролами, которые были бы одинаковы для flash и html5 версии. Но это надо делать, и мне было лень. Да и наверняка уже есть.

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

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

Возможно я не совсем понял вопроса, но…

var data = (function(){
    var a = "provate string";
    var b = "public string;";

    return {
        a: a
    };
})();

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

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

Готовое не знаю, но можно написать простенький лексер/парсер. Лексер будет разбирать это все на слова, и знаки препинания. Затем вы просто основываясь на потоке лексем формируете новую строку. А можно при помощи регулярок с последующим анализом вхождений.

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

Обычно для интернет-магазинов EAV структура приблизительно следующая:
Категория (* — *) Опция ( 1 — *) Значение ( * — 1 ) Продукт
Поиск товаров допустим реализуется через INNER JOIN и создает довольно большие накладные расходы. Это единственный, и довольно существенный минус этого подхода. Решается он использованием вьюх в базе данных, или же NoSQL решений. Так же есть варианты использовать фасеточный поиск, например через Sphinx. Но гибкость разработки как по мне довольно большой плюс.

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

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

Смысла особо нету. Вы можете взять любой фреймворк под PHP 5.3 (Symfony2, Zend2, Yii2 который выйдет) и использовать там все прелести PHP5.4 сколько захотите.
По сути, все нововведения PHP5,4 конкретно фреймворку не нужны. Трейты? это макросы обычные. Содержимое трейта заменяет метко использования трейта в коде — ничего больше. Код по сути все так же дублируется. Как по мне использование трейтов должно быть сведено к минимуму. Не могу придумать такой ситуации когда они реально нужны. Для себя я использовал трейты только для моделей Yii 1.* что бы не писать каждый раз в модели метод model().
Синтаксический сахар полезен только для пользовательского кода (конфиги, для моделей и контроллеров), то же относится и к остальным плюшкам.
Единственная полезная вещь в PHP 5,4 — увеличение производительности, но опять же на код и архитектуру фреймворка это никак не должно влиять.

Вобщем, ничто не мешает использовать PHP 5,4 с имеющимися фреймворками.

Если такой ответ вас не устроит, присмотритесь к auraphp. Архитектура оного мне чем-то напоминает ужасную смесь Yii и Symfony2 со своими прелестями. Но там тоже «мощь» PHP5,4 не особо используется, опять же так как это лишено смысла.

Вот если бы ввели аннотации/атрибуты объектов…

я использовал Yii с момента выхода 1.0. Это очень удобный фреймворк на котором можно развернуть что-либо достаточно быстро. К сожалению, с простотой использования приходят проблемы. А именно — нулевое комьюнити, быдло-разработчики и т.д. Сами расширения для фреймворка очень отличаются друг от друга не только по качеству, но и по реализации. Мне допустим не понятно зачем нужна такая большая иерархия компонентов, виджетов, расширений… Да и грядущая ветка Yii 2 особо погоды этому фреймворку не делает. Так что, как это не печально, перспектив у него мало. Только для начинающих было бы полезно его знать.

Zend не люблю с первых версий, и это сугубо субъективно. Это довольно качественный фреймворк (только с версии 2.0) который было бы полезно потыкать.

По работе пришлось сменить уже привычный Yii 1.* на Symfony 2. По началу я плевался от всех этих «по феншую». Необходимость на каждую пропертю в модели писать свой геттер/сеттер (использую в связке с Doctrine2). Но сама концепция «компилируемый» php мне очень нравится. Аннотации (к слову, очень жаль что тикет с просьбой добавить их нативно убрали), контейнер зависимостей и прочее делают разработку более элегантной. Как уже говорили выше — этот фреймворк просто заставляет писать хорошо (хотя плохо написать очень даже возможно). Если сравнивать качество решений для этих трех фреймворков, пожалуй пока лидирует Zend, но решение для оного легко переносятся на Symfony.

На данный момент самый перспективный фреймворк — Symfony 2 (причем сразу можно брать на изучение 2,1). Остальные же — тоже довольно интересны и познавательны, но я к ним по своей воле уже не вернусь.

Просто массив структур содержащих данные о вокселах. Правда мне казалось что данных должно быть больше, ну да не суть.

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

Из популярных Joomla не рассматривается мною как CMS уже года два. Не буду опускаться до грубых оскорблений… но настрадался я с ней в свое время.

Wordpress — замечательная CMS с точки зрения конечного потребителя. Удобная, гибкая… Правда самая большая печаль этой замечательной CMS — комьюнити разработчиков, которое, судя по коду, составляют студенты и школьники. Качество кода мягко скажем… ужасное. Вся логика по сути храниться в шаблонах. Что бы реализовать что-то понастоящему дельное приходится сильно думать. Особенно острой встает проблема производительности. Помниться, на одном сайте-визитке WP генерил порядка 150 запросов на страницу. Кэширование помогает конечно, но это тихий ужас.

Drupal — вот тут уже противоречивое мнение оставила эта CMF. По сути, качество реализации намного выше аналогичных. Поддерживается, много разработчиков, если хорошо покавырять напильником — в меру удобная… Но очень любит стандартизацию, в чем и плюс и минус. И да, порог вхождения у нее повыше чем в WP и Joomla, от того качественных плагинов больше.