Введение

Это статья написана, чтобы иллюстрировать применение возможностей Common Lisp к типичным задачам веб-разработки.

Я постараюсь показать, как на лиспе реализовываются основные применяемые в веб-программировании вещи — шаблонизация, роутинг и кеширование. Также я оставил немножко места для макросов.

Статья в большой степени учебная, тем не менее это вполне работающий веб-сайт — rigidus.ru

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

Прелюдия

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

В рамках данной статьи я поделюсь своим опытом проектирования сайтов средней сложности. Данный подход зарекомендовал себя понятным как разработчикам, так и клиентам. Я не собираюсь открывать Америку, представленные ниже инструменты всем прекрасно знакомы. Суть данной статьи как раз в том, что бы продемонстрировать насколько просто можно представить достаточно сложные задачи.

Преимущества дивной вёрстки, семантичной разметки и разделения содержимого и дизайна описаны десятки, сотни раз, но все-равно находятся люди, которые не понимают самой идеи html и css, пишут в коде такие ужасные вещи, как

<span style="color:blue">

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

<font color="blue">

, наивно веря в этом деле валидатору. А ведь правильный подход в написании html и css лежит на поверхности. Достаточно просто посмотреть историю развития этого языка, почитать статьи десятилетней давности и проанализировать. Я, при поддержке theshock, постаралась в этот статье упорядоченно и коротко изложить наше видение этого вопроса.

В данном обзоре я расскажу о реализации кластера состоящего из двух нод с резервированием популярной связки для веб сервера Apache + MySQL + FreeBSD (или любой Linux).

Часть 2
Часть 3

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

В части первой:
• Создание простого Comet — приложение, которое посылает клиентам сообщение каждые 10 секунд.
• Настройка ядра Linux для поддержки большого количества соединений.
• Создание тестирующей утилиты для создания большого количества соединений.
• Определение необходимого количества памяти.

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

Предполагается, что Вы знакомы с bash, и немного с Erlang.

Часть 1
Часть 3

В части 1 мы создали (немного бесполезное) mochiweb приложение, которое отправяет клиентам сообщение каждые 10 секунд. Мы настроили ядро Linux, и создали инструмент, чтобы установить много соединений для проверки использования памяти. Мы выяснили, что требуется приблизительно 45 Кб для каждого подключения.

В части 2 мы превратим наше приложение во что-то полезное, и уменьшим потребление памяти:
• Реализация маршрутизатора сообщения с login/logout/send API;
• Обновление mochiweb приложения для работы с маршрутизатором;
• Установка распределенной erlang системы, таким образом, мы можем запустить маршрутизатор на различных узлах;
• Создание инструмента тестирования маршрутизатора большим количеством сообщений;
• График использование памяти в течении 24 часов, оптимизация mochiweb приложение для экономии памяти.

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

Поскольку новость не пробежала на Хабре, но однозначно (с) будет интересна многим:

«Видео с пользовательской конференции по Sphinx (~8часов)
http://devconf.tv/user/sphinx».

Приятно удивившись ажиотажу вокруг предыдущего материала, я решил пойти дальше. На этот раз, под прицелом – интернет-магазины. Их ошибки, глупости и т.п.



Итак…

1. Отсутствие фирменной концепции (логотипа, слогана, и т.п.).

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

Многие владельцы интернет-магазинов банально не понимают (лично спрашивал) – огромная часть продаж строится на бренде. У человека в голове есть ряд ячеек, заполненных брендами известных фирм. К примеру, «наушники – Koss», «операционная система – MacOS X», «газировка – Coca-Cola», и т.д. и т.п. Первоочерёдная задача фирменой концепции – заполнить ячейку «интернет-магазин — ?» вашим названием. Тогда пользователь будет возвращаться снова и снова.

Это шестая, заключительная часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»
• «Привыкаем работать в команде»
• «Исправляем ошибки»
• «Процесс слияния»

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

Часть 6. Архитектура репозиториев

Наш рецепт становится все лучше:

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



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

#1: Текст главной страницы

Надеюсь, не нужно объяснять, насколько важен для web-сайта хороший текст. Особенно, если сайт коммерческий. Но, в то же время, тексты 90% сайтов web-студий СНГ бесполезны. Почему я так считаю?

Давайте посмотрим на вопрос со стороны заказчика и будем предельно откровенны. Сколько студий «уже 10 лет на рынке web-разработки»? Сотни. В скольких студиях «работают только квалифицированные специалисты»? Во всех. У какой студии «самая качественная и расширяемая CMS»? У каждой.

Данная статья давно назревала в моей голове, но совсем в ином формате.
Прочитав последние несколько неуклюжих статей на тему WEB-сервисов (например: http://habrahabr.ru/blogs/development/108973/) и применения в них REST технологии, решил что настало время все-таки откинуть лень, выделить время и написать «переформатированную» в своей голове статью.
Итак, кратко, что Вы найдете в статье и кому она будет полезна:

— новичкам, которые интересуются или планируют написать WEB-сервис для проекта
— профи вряд ли найдут что-то новое для себя
— общая идеология REST
— применение CRUD в WEB-сервисах
— принципы KISS при построении раутеров
— лучшие практики
— немного пиара ;)
— ссылки, литература

Привет, ребята! С этого момента я хочу начать цикл статтей с подробностями по созданию сообственного MVC фреймворка для node.js, название которому будет — Spirit.

Первая статья будет состять из четырех частей:
1. Идея и миссия фреймворка
2. Настройка сервера
3. Создание каркаса фреймворка
4. Создание продвинутого и удобного роутера

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

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

4 октября выпущен Firebird 2.5, 5-й релиз реляционной СУБД с открытым кодом. Пресс-релиз (английский) здесь, скачать дистрибутивы и исходные коды можно на www.firebirdsql.org. Доступны 32- и 64-битные версии для Windows и Linux, MacOSX, Solaris и HP-UX появятся позже.

Новые возможности Firebird 2.5

• Новая архитектура SuperClassic. Firebird 2.5 представляет новую архитектуру под названием SuperClassic, которая позволяет получить большую отдачу от многопроцессорных и многоядерных серверов, и работать с еще большим количеством пользователей
• Аудит. Новые функции Services API позволяют вести аудит запросов к серверу практически в реальном времени, и анализировать все запросы, выполняемые над базой данных.
• Запросы между базами данных. Firebird 2.5 позволяет из хранимых процедур, триггеров и блоков кода одной базы данных обращаться к другим базам данных Firebird.
• Расширенное управление пользователями. Управление пользователями теперь доступно через SQL-операторы
• Другие возможности включают в себя автономные транзакции в коде PSQL (хранимых процедурах, триггерах и блоках кода), регулярные выражения в SQL – SIMILAR TO, асинхронное отключение соединений, расширения возможностей мониторинга и многое другое.

Более подробную информацию о всех нововведениях можно прочесть в документе Release Notes Firebird 2.5.

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

Введение

Описано было довольно хорошо вот здесь.

Как его подключить

Если у Вас версия 22 и выше — он у Вас уже установлен. Если нет — установите новую версию. :)

В субботу 25-ого сентября 2010 в 17.00 мы открываем новый сезон семинара по автоматической обработке естественного языка. На первом заcедании этого учебного года выступит Эдуард Клышинский (Институт прикладной математики им. М.В. Келдыша РАН. Москва) с рассказом о принципах построения программного модуля морфологического анализа и синтеза для русского языка. Доклад называется «Давайте напишем морфологию».
Семинар будет транслироваться в он-лайне, позже мы выложим презентацию и видеозапись на сайт семинара.

Несколько часов назад мы выпустили рекомендации по безопасности в ASP.NET (Microsoft Security Advisory). Эта уязвимость существует во всех версиях ASP.NET.

Эта уязвимость была публично раскрыта вечером в пятницу на конференции по безопасности. Мы рекомендуем все клиентам использующим ASP.NET немедленно применить временное решение (описанное ниже) для предотвращения атак с ее использованием.

Статья будет полезна в первую очередь разработчикам, которые теряются на собеседованиях когда слышат вопрос «Назовите основные отличия синглтона от статического класса, и когда следует использовать один, а когда другой?». И безусловно будет полезна для тех разработчиков, которые при слове «паттерн» впадают в уныние или просят прекратить выражаться :)

Что такое статический класс?

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

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

1 Коротко и неясно

1. ЧИТАЙ КОД!
   
2. Пиши код, который удобно читать всем остальным
   
3. Пиши в комментарии не ЧТО делает код, а ЗАЧЕМ
   
4. Предупреждения и подсказки опаснее ошибок компиляции — проект собирается без их устранения
   

2 Цикл разработки

1. Постановка задачи руководителем
   
2. Выработка решения
   
3. Рецензирование решения
   
4. Реализация решения
   
5. Рецензирование кода
   
6. Размещение в системе контроля версий