Каркас для кроссбраузерной разработки ExtJS сейчас очень популярен. Это поистине грандиозный (и монструозный) набор компонентов, классов, функций, хелперов и т. п., которые могут как облегчить жизнь разработчика, так и усложнить ее. Говоря вообще, ExtJS (до 4-й версии) не устанавливает никаких «правил игры» для конечного разработчика: формально нет никаких требований и рекомендаций по проектированию и написанию надежных приложений.
Удивительно, что до сих пор качество пособий и туториалов для новичков ExtJS, мягко говоря, оставляет желать лучшего. Как и стандартная справка по ExtJS API, впрочем [1].
Цель данной статьи — показать, как писать приложения на базе ExtJS так, чтобы человеку, который будет поддерживать ваш код, не хотелось рвать волосы, а вам просто не было стыдно. А если серьезно, то в данной статье я предложу простой и короткий набор правил проектирования и написания приложений применительно к данному фреймворку.

Эта статья — перевод статьи из блога www.swarmonline.com с небольшими моими дополнениями

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

В этой статье мы собрали список некоторых из вещей, которые рекомендуем вам делать, когда вы начинаете работать с Ext JS (даже, если вы ветеран разработки, всё равно можете узнать что то новое!). Эти вещи прошли через наш опыт, через просмотр и ответы на одни и те же вопросы на форумах. Это наиболее общие из лучших техник программирования.

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

Одновременная межсайтовая аутентификация (SSO), для чего же она нужна? Допустим у нас есть, назовём его анахроничным термином «портал», с блогами, фотками, фейлами (или файлами, кому как), назовём его fail.ru (не путать с одноимённым сервисом почты на букву М), причём всё это усложнено следующими факторами:
— функционал совершенно разный;
— код написан разными людьми, с испольованием разных технологий;
— работает всё это на разных серверах в разных датацентрах и с разными базами данных;
— сервера находятся на разных доменах.

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

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

Далее мы рассмотрим самописные альтернативы, OpenID, OAuth, SAML, и почему всё это в общем случае не слишком хорошее решение, вопросы хранения аутенитификационных данных, а также некоторые вопросы безопасности в которые без хороших знаний самому лезть не стоит, что такое вообще межсайтовая аутентификация, развеем некоторые мифы.

В компании, где я работаю, мы используем деперсонализированную базу с Production-a. Ее суммарный объем на данный момент около 30 ГБ. Обфускация ruby скриптом занимала около 6 часов. Ускорение обработки можно добиться, если переписать это все в хранимую процедуру (stored procedure). Но у нас в проекте они запрещены… Увы и ах.

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

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

Проблема довольно острая, потому что быстродействие является критически важной характеристикой UI. Например, по оценке Amazon, задержка загрузки страницы всего лишь в 0,1 секунды приводит к снижению оборота магазина на 1%. По оценке Google, задержка в 0,5 секунды уменьшает количество поисковых запросов на 20%.

Ruby/JavaScript-разработчик Алекс Маккоу (Alex MacCaw) из компании Twitter предлагает логичное решение проблемы: распространить принципы Ajax не только на фронтэнд, но и на пользовательский интерфейс. Он разработал соответствующий фремйворк для того, что называется AUI (асинхронный интерфейс пользователя).

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

Я являюсь автором программы для автоматического переключения раскладки клавиатуры, работающей под Linux. Эта программа xneur или X Neural Switcher.

Когда я начинал заниматься этой программой, ничего вменяемого для замены Punto Swither для linux не было. Обратите внимание, я писал ее лично для себя, у меня почти всегда все работает. Я выкладываю ее в общий доступ только потому, что программа полезна людям.

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

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

За прошедшие 6 лет, я периодически натыкался на специфические баги как Xlib, так и DE, c которыми приходилось находить взаимопонимание.

Сейчас я хочу рассказать о приготовлении xneur, описать настройки и поделиться «маленькими футбольными хитростями».

Эта часть статей под номером 0 посвящена самому простому — описанию. Вы удивитесь, как много xneur умеет из того, что не умеет Punto.

Для тех кто долго пробовал, но не осилил. Я всегда открыт к диалогу. Если что-то где-то не работает, сообщите мне всю необходимую информацию, и я постараюсь решить вашу проблему.

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

Вкратце:

• Хотят сотрудники работать по умолчанию или нет?
• Почему авторитарные лидеры вымирают.
• Насколько важно распространение информации (менеджмент «открытых книг»).
• Кто не косячит – тот не работает.
• Как мы собеседуем.
• Как мотивировать команду.
• О рандомных премиях.
• Корпоративы: может, лучше дать всем по $100?

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

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

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

Хочу поделиться ссылками на несколько полезных сервисов. Некоторые из них помогут сэкономить время, другие — сделают за Вас незнакомую/нелюбимую работу. Список разбит по категориям, чтобы было легче ориентироваться.

Сервисы опросов
userreport.com (добавил Romanych)
simpoll.ru
webanketa.com (добавил mihass)

Кнопки постинга в социальные сети
Кнопка от Яндекса
addthis.com (добавил UksusoFF)
share42.com

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

Из последних сил и отбросив такт, ты начинаешь свой рассказ.

Около 2-х месяцев назад я и TheShock собирали вопросы по JavaScript в теме FAQ по JavaScript: задавайте вопросы. Первая часть, те вопросы, которые достались мне, появилась буквально через несколько дней JavaScript F.A.Q: Часть 1, а вот вторая часть все не выходит и не выходит. TheShock сейчас переезжает в другую страну и поэтому ему не до ответов. Он попросил меня ответить на его часть. Итак вторая часть ответов — те вопросы, которые достались тоже мне.

Давно подметил, что веб-проекты отличаются разными классами «свежести»…

Первой свежести

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

Для менеджера управлять развитием такого продукта, путем итераций + ТЗ, или путем работы в доверительном Scrum/Agile-режиме — приятно. Зазубрины некритичных рисков и фрагментальных сдвигов сроков сглаживаются общим ощущением надежности и жизнеспособности продукта. Менеджер горит идеями, богатеет фичами, а после регулярной реализации самых приоритетных задач получает дозу морального удовлетворения и оптимизма… и желает дальше работать в этой компании :-)

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

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

К сожалению, такие проекты/продукты встречаются… нечасто. Но — встречаются.

Второй свежести

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

В работе первые 90% проекта делаются за 10% времени, оставшиеся 10% — за 90%
Народная мудрость

В работе очень важным является доведение до конца.

Существует всего одно результативное состояние у задачи — «сделано». Все остальные — почти, еще чуть-чуть, немного осталось, сделал наполовину, и т.д. — это состояние, которое я называю «не сделано».

Согласно одной статистике, 4-5% людей обладают талантом предпринимателя (от слова «предпринимать»). Думаю, не сильно больше — талантом доводить до конца.

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

Бороться до конца — вот кредо настоящего профессионала (умение резко переключиться под нужды, ясное дело, также нужно:).

Теперь пример доведения дела до конца в рамках целого проекта.

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

Мне нравится подразделять эти ошибки на три большие группы: провалы, погрешности и недочеты. Провал – это когда ты сидишь тупо смотришь на экран и тихо говоришь «ой»; вещи вроде удаления базы данных или целого сайта, записи чего-либо поверх результата трехдневной работы, или случайной отсылки письма 20 тысячам человек.

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

Когда ошибка настолько неочевидна и неуловима, что это почти прекрасно, я зову это недочетом. Такое случается, когда кусок кода сталкивается с совершенно непредсказуемыми и весьма маловероятными обстоятельствами. Вы откидываетесь на спинку стула и думаете «Ого!», словно увидев яркую радугу или падающую звезду.

Для проверки текстовых полей на валидность обычно используют регулярные выражения. Существует несколько наиболе распространенных видов таких даных, как например номер кредитки, дата в определенном формате и т. д. На сайте html5pattern.com собирается коллекция регулярных выражений для таких данных (там это позиционируется, как возможное содержимое html5-атрибута pattern у inpit-элементов, но эти регулярные выражения можно использовать и для привычной валидации с помощью javascript). Актуальные для российской аудитории примеры, вместе с соответствующими регулярными выражениями вы можете посмотреть под катом.

Многие уже в курсе, что 1 июля окончательно вступили в силу положения закона ФЗ-152 «О персональных данных». Федеральный закон, регулирующий деятельность по обработке (использованию) персональных данных, претерпел значительные изменения, которые могут сильно подпортить бизнес большинству компаний.

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

В связи с тем, что на данный момент менее 5% компаний готовы соблюдать эти требования, на рынке появилось множество системных интеграторов и специалистов в области информационной безопасности, готовых помочь компании продолжить работать в штатном режиме за N-ую сумму (от 10 000 рублей до unlim рублей).

На Хабре мелькали статьи, в которых авторы призывали системных администраторов и IT-менеджеров готовиться к «судному дню».

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

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

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

Из институтского курса по технологиям программирования я вынес следующую классификацию видов тестирования (критерий — степень изолированности кода). Тестирование бывает:

• Блочное (Unit testing) — тестирование одного модуля в изоляции.
• Интеграционное (Integration Testing) — тестирование группы взаимодействующих модулей.
• Системное (System Testing) — тестирование системы в целом.

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

Итак, этот пост будет немного «поспешным», что неудивительно для субботнего утра (оригинальная статья была опубликована 18-ого августа 2007-ого года. прим.пер.), но я хочу сослаться на этот топик в одной работе, которой собираюсь заняться этой осенью. Я планирую плодотворно поработать: создать несколько ресурсов со ссылками в интернете, которые помогут детям в создании своих первых проектов, а также в обучении таким предметам как физика, физика космоса и робототехника/электроника. Если вы знаете меня, то вы знаете, что я довольно долго изучал эти вещи. Проблема в процессе обучения этим предметам в наше время в том, что они чересчур абстрактны и часто ограничиваются теорией «на бумаге». Чтобы изучить эти предметы на уровне более высоком, чем просто знание тривиальных вещей и фактов, вы должны по-настоящему «заниматься» наукой, а не просто «читать» о них.

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

Без малого год назад, я уже писал (http://habrahabr.ru/blogs/javascript/50544/) о самом коротком способе определение браузера Internet Explorer, но вот некто Aleko нашел еще более короткий вариант:

-[1,]

Всего 5 байт. Пример использования:
if(-[1,]){
alert("Not IE!");
}