Бесшумный ПК без вентиляторов на 2.2GHz Intel Core 2 Duo. Подчеркну, что это серийная модель, а не концепт. Дело бесшумных машин живет и побеждает!

Dell анонсировала 14-дюймовый ноутбук Dell Studio 14z. Особенность лэптопа – чипсет NVIDIA GeForce 9400M, который, как известно превосходит встроенную графику от Intel. Модель будет поставляться в шести цветовых вариантах и трех модификациях. В зависимости от варианта, стоимость новинки колеблется от 650 до 900 долларов.

Lenovo наконец-то объявила 12-дюймовый ноутбук на платформе NVIDIA Ion. Машинка будет называться Lenovo's S12.

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

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

1. Главная страница выглядит блекло и безлично
Что видит ваш посетитель, попадая на главную страницу магазина? Может ли со 100% уверенностью сказать, что это интернет-магазин? Может ли он узнать, чем торгует этот магазин? Типичной ошибкой является пренебрежение к законам коммерческого дизайна. Помимо мелкого шрифта и отсутствия должного описания, часто не всегда удается найти центр композиции. Все тексты и картинки выглядят или второстепенным или же каждый элемент пытается «перекричать» соседний. Вспомните, как выглядит газета бесплатных объявлений, заполненная массой пестрых рекламных блоков.

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

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

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

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

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

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


Основной проблемой является то, что реляционные базы данных не могут справляться с нагрузками актуальными в наше время (мы говорим о high-load проектах). Есть три конкретные проблемных области:

• горизонтальное масштабирование при больших объемах данных, например как в случае Digg (3 терабайта для зеленых значков, отображаемых, если ваш друг сделал dugg на статье) или Facebook (50 терабайт для поиска по входящим сообщениям) или eBay (2 петабайта в целом)
• производительность каждого отдельного сервера
• не гибкий дизайн логической структуры.

Приветствую читателей. Сейчас я веду разработку собственного фреймворка, основанного, в противовес главенствующей сейчас модели MVC, на базе сигнальной архитектуры (signal/slot). Пока он проходит боевую обкатку в нашем стартапе, и за это время я понял, что просто библиотеки мало — реальные задачи и виденье будущего показывает, что необходим разный функционал, но объединенный одной темой — обработка и доставка информации множеству клиентов в реальном времени (да, в чем-то схоже с Comet-ом, он там тоже есть). Поэтому решено было попробовать реализовать основной компонент — очередь сообщений, которая бы стала основной для следующих проектов, быстрой, гибкой и масштабируемой.

Что получилось? Альфа-версия SignalsyMQ — очередь сообщений на базе PHP/Redis/Zend Framework.

Введение

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

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

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

Защита (или отсутствие защиты) от различных типов атак демонстрируется на примере протоколов популярных сегодня систем: Assist, Cyberplat, WebMoney, ChronoPay, Robokassa и PayPal (платёжные системы), а также OpenID, OpenAuth, OAuth (децентрализованная аутентификация).

Практически любая информационная система характеризуется наличием системы хранения и оперирования данными. Возьмем, к примеру, обычные веб-сайты. Для их создания обычно используются какие-либо готовые системы (фреймворки или уже готовые CMS), в которых изначально уже заложена какая-то концепция по работе с данными, установившаяся предметная область. Обычно, если разработчик хочется добавить на сайте раздел новостей, он добавляет в интерфейсе CMS компонент, информационный блок, шаблон и т.п. Суть всех этих конструкций одна — создать сущность в БД для хранения (либо каком-то ином хранилище). В итоге имеется реляционная база данных и, зачастую, какой-то объектно-ориентированный обвес, реализующий связку объект-атрибуты-свойства-методы — реализуется предметная область.

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

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

Мистер Томпкинс — человек уже довольно приличного возраста. Первое знакомство с ним состоялось в далеком 1938 году, когда физик и одессит Георгий Антонович Гамов опубликовал в Британском журнале Discovery серию рассказов о человеке, который в своих снах попадал в альтернативные миры, где значения физических констант радикально отличаются от значений оных в реальном мире, что приводит к совершенно неожиданным результатам. Так Гамов популярно объяснял концепции современной физики неискушенному читателю. Незадачиливым же соней был тот самый Мистер Томпкинс.

Практически 60 лет спустя Том ДеМарко решил поделиться свой безграничной мудростью и в столь же популярной форме преподнести идеи из Peopleware, написанной в соавторстве с Тимоти Листером. Итогом стал "Роман об управлении проектами", в котором наш старый знакомый Мистер Томпкинс похищается сексапильной брюнеткой Лаксой Хулигэн и увозится в загадочную страну Моровию, где ему представляется возможность провести настоящий эксперимент по управлению проектами разработки программного обеспечения…

В конце каждой главы Мистер Томпкинс подводит итоги и записывает свои мысли, которые, по сути, являются аксиомами и постулатами управления проектами по ДеМарко и Листеру. Разумеется, лучше будет прочесть всю книгу в целом — иначе не понять, как эти принципы применяются в «реальной» жизни. Но если времени нет (или же просто хочется освежить память), то вашему вниманию предагается…

Стэнфордский курс по основам языков программирования выложен на YouTube.



27 лекций минут по 20 каждая ведут стэнфордский преподаватель Джерри Кейн (экс-Стэнфорд, нынче Facebook), последняя лекция по Haskell преподается Сашей Рашем (Facebook). Рассматриваются концепции и основы C (куда ж без него), ассемблера, C++, Scheme, Python и Haskell.

InfoVis Toolkit — предоставляет инструменты для создания интерактивных представлений данных в Веб с помощью JavaScript. Распространяется с открытым исходным кодом под лицензией BSD. Поддерживаются основные браузеры: IE6+, Firefox2+, Safari3+, Opera9.5+

Те из вас кто следит за автором на Github могли заметить, что недавно он добавил новый проект под названием «prettyPrint».
«prettyPrint» — браузерный дампер переменных для JavaScript аналогичный cfdump для ColdFusion. Он позволяет выводить на экран объекты любого типа в виде таблиц для просмотра во время отладки.
Посмотреть пример.

Не так давно в комментариях к топику AlexS высказал идею использования соглашения об оформлении на Хабре кода примеров темы .Net написанных на C#.

Я немного поизучал имеющиеся предложения из этих источников:
submain.com/blog/FreeCVBNETCodingGuidelinesEbookDownload.aspx
idesign.net/idesign/DesktopDefault.aspx
и скомпилировал черновик который описывает самые базовые правила оформления кода написанного на C#.

Предлагаю:
— обсудить этот черновик;
— внести в него все необходимые изменения;
— утвердить как стандарт написания C# кода на Хабре.
Более того, предлагаю создать документ, который можно было бы предложить как рекомендации habrahabr comunity для всех других программистов C#.

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

Предлагаю мой вольный перевод вопроса с stackoverflow, который мне показался полезным и сидит в фаворитах. Что-то я взял с MSDN (в основном вырезки из русской редакции), что-то -с блогов.
Все мы, С# разработчики, знаем базовые комманды C#. Я имею ввиду объявления, условия, циклы, операторы и т.д.
Некоторые из нас знают даже про Generics, anonymous types, lambdas, linq,…

Но, каковы реально скрытные возможности и трюки C#, про которые даже фанаты и эксперты не всегда знают?

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

CMS может просто передавать данные по запросу клиентскому приложению, например сетевой программе, flash-клипу или AJAX-приложению. Но чаще всего, CMS предоставляет клиенту уже подготовленные для отображения данные в HTML формате. В этом случаи, для обеспечения доступности, легкости восприятия и удобства пользования содержимым, выполняется стилизация и объединение его с элементами оформления (темы, шаблоны), навигации (меню, ссылки) и управления (формы и ссылки тоже), и всем этим тоже нужно управлять.

Идея

Окружающий мир воспринимается нами объектным, мы мыслим «объектами», в наших умах выстраивается объектная модель мира. Поэтому нам не составит труда создать объектную модель содержимого сайта и управлять ею. Новости, товар в каталоге, сообщения на форуме и сами форумы, и все другое можно представить в виде объектов. Устанавливая связи между объектами, можно создавать структуры данных любой сложности, от добавления комментариев к статьям до создания социальных сетей и более.

Объекты, классы и связи данных – это информация, которую нужно уметь создавать, хранить, использовать, изменять и удалять. В нашем распоряжении реляционная база данных для хранения информации. Действия же совершаемые с информацией – часть логики функционирования CMS, которая в большей части будет реализована модулем данных Data.

Имея более чем достаточно времени, увлекся я размышлениями о создании гибкой, многофункциональной, но относительно простой CMS для программистов и её конфигураторов-пользователей. Некоторые идеи были навеяны потенциальными возможностями CMS Drupal. И вот теперь, увлеченный уже реализацией идей и имея успешные промежуточные результаты, я решил рассказать об архитектуре создаваемой CMS. По ходу прочтения общая картина возможностей CMS должна прорисовываться сама, во всяком случае, для программистов:)

Архитектура CMS

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

JS Charts является бесплатным JavaScript-генератором графиков и схем, который требует минимум знаний программирования. С JS Charts рисование диаграмм становится простой и легкой задачей. Он не требует никаких дополнительных плагинов и серверных модулей. Просто подключите скрипты, подготовьте данные для схемы в XML или массиве JavaScript и ваша таблица готова.

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

Перевод отличной статейки. Думаю, будет полезна как новичкам, которые только приступили к использованию jQuery, так и тем, кто уже какое-то время с ним работает. А кого-то, возможно, заставит глянуть эту чудесную библиотечку. Многие советы имеют отношение не только к jQuery, но и к JavaScript в целом. Лично для меня была весьма и весьма познавательной, посему и захотелось донести это «до масс». Перевод не дословный, но передающий смысл и максимально адаптированный к русскому языку.

Далее все написано от имени автора оригинальной статьи.

Введение

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

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

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

Содержание

1. Загружайте фреймворк с Google Code
2. Используйте «шпаргалку» (cheat sheet)
3. Соединяйте все ваши скрипты и уменьшайте размер файла
4. Используйте возможности Firebug для ведения логов
5. Минимизируйте операции выборки в пользу кэширования
6. Сводите манипуляции с DOM-деревом к минимуму
7. Оборачивайте все в единый элемент, когда речь идет о любой вставке в DOM
8. Используйте «id» вместо классов, где это возможно
9. Задайте контекст своим селекторам
10. Используйте последовательности вызовов методов с умом
11. Научитесь правильно использовать анимацию
12. Научитесь назначать и делегировать события
13. Используйте классы для сохранения состояния
14. Еще лучше — используйте встроенный в jQuery метод data() для сохранения состояния
15. Пишите собственные селекторы
16. Подготавливайте HTML и модифицируйте его, когда страница загружена
17. Используйте «отложенную загрузку» (lazy loading) для определенного контента для выигрыша в общей скорости и преимуществ для SEO
18. Используйте служебные функции jQuery
19. Используйте «noconflict» для переименования глобального объекта «jquery», когда используете его с другими фреймворками
20. Как узнать что картинки загружены?
21. Всегда используйте последнюю версию
22. Как проверить, что элемент существует?
23. Добавляйте класс «JS» в элемент «html»
24. Возвращайте «false» для отмены поведения по-умолчанию
25. Короткая запись для события готовности документа

Вступление

Забавно, но когда программист разрабатывает какой-либо продукт, он редко задумывается над вопросом могут ли на одну кнопку в один момент времени нажать одновременно 2000 человек. А зря. Оказывается могут. Как ни странно но большинство движков, написанных такими программистами, очень плохо ведут себя под большими нагрузками. Кто бы подумал, а всего один лишний INSERT, не проставленный index, или кривая рекурсивная функция могут поднять load averages чуть ли не на порядок.

В этой статье я опишу как мы, разработчики проекта, сумели выжать из одного сервера с Pentium 4 HT / 512Mb RAM, максимум, держа одновременно 700+ пользователей на форуме и 120,000 на трекере. Да, проект этот — торрент трекер. Предлагаю сразу оставить в стороне разговоры о копирайтах и правах, мне это не интересно, что действительно интересно — это HighLoad.