Хабрахабр:
17 октября у нас пройдет осенний Форум Технологий Mail.Ru Group 2012. На осенний Форум приглашены 24 спикера, доклады пройдут в 3 потока. Форум Технологий мы проводим уже в четвертый раз. Весной мы делали специальную версию Форума для системных администраторов. Этой осенью, так же как и прошлой, темой станет веб-разработка, в самом широком смысле. Мне хотелось бы познакомить вас с темами и докладчиками, с технологиями и идеями. Мы пригласили на Форум несколько интересных западных спикеров. Много о чем впервые расскажем, вас ждут живые демонстрации и мастер-классы. В этом посте мне хотелось бы познакомить вас с темами, которые будут подниматься в этот раз, и с нашими докладчиками. Задавайте вопросы в комментариях — выступающие еще успеют учесть их в своих презентациях. И готовьте вопросы к Форуму, мы их очень любим и ценим. Участие бесплатное, но количество мест ограничено, регистрация обязательна и скоро уже закроется. Читать дальше →
Вы отвечаете за стабильность работы веб-проекта на PHP. Нагрузка постоянно растет, добавляются фичи, клиенты довольны. В один прекрасный день начинают появляться загадочные ошибки? Ошибки серверного софта ? которые программисты не знают как исправить, т.к. ?ломается? серверный софт, например связка apache-PHP ? а клиент получает в ответ на запрос страницу о регламентных работах. Веб-разработчик часто не обладает глубокими знаниями в программировании на C в unix/linux, а сисадмин нередко, к сожалению, глубже bash в систему не погружается. Настоящий хардкор :-) Нестабильная работа серверных скриптов Нередко, определенные страницы веб-проекта начинают сходить с ума. Например выполняться по 15 минут и выяснить, чем же они занимаются, непросто. В прошлом посте на данную тему я описал одну из методик определения, чем занимается PHP-скрипт на боевом сервере, но чувствуется, что нужен более мощный инструмент. На практике я часто встречаю проекты, которые сталкиваются с подобным классом ошибок ?серверного софта?, и в команде не всегда знают, что делать. В логе apache часто появляются сообщения о нарушении сегментации (semgentation fault), клиенты получают страницу об ошибке, а веб-разработчик с сисадмином ломают себе голову, играются с разными версиями PHP/apache/прекомпилятора, собирают PHP из исходников с разными опциями снова и снова, пишут о багах, а им доказывают, что это баги не PHP, а их кода и так до бесконечности? В статье я хочу рассказать как можно просто и быстро найти причину, почему PHP рассыпался на боевом сервере и устранить ее ? не погружаясь в прекрасный мир системного программирования на C для unix :-) От вас потребуется желание и одна чашечка кофе. Читать дальше →
С каждым днём во мне крепнет осознание того, что JavaScript стремится играть ту же роль (занять ту же нишу), которая была свойственна Бейсику лет тридцать или даже пятнадцать тому назад. Иными словами, JavaScript становится простым и распространённым языком, далеко переросшим своё первоначальное предназначение, и на нём теперь можно сочинить почти какое угодно приложение (и клиентское, и серверное, и консольное? и даже с GUI, как я недавно убедился). Создаются целые операционные системы (Firefox OS, Google Chrome OS, Open webOS), для которых JavaScript является не менее ?родным?, чем Си для UNIX в своё время. Появляются языки, транслируемые в JavaScript (можно вспомнить CoffeeScript, Dart, новорождённый TypeScript, и так далее). Заметив это, уместно тотчас же порадоваться тому, что к джаваскрипту предъявляют, по крайней мере, меньше серьёзных претензий, чем некогда к Бейсику, который по справедливости невзлюбили за его GOTO и поощрение ?макаронного кода?. Притом джаваскрипт гораздо лучше переносится и с платформы на платформу, и из браузера во браузер. Кроме того, многие существующие проблемы джаваскрипта не имеют особенного значения, потому что устраняются широко распространёнными средствами с открытым исходным кодом. Так, нестрогость синтаксиса устраняется строгою проверкою исходного кода (JSLint, например). Нехватка средств обработки данных (массивов, объектов) и функций устраняется подключением Underscore, а строки помогает обработать Underscore.string, а даты ? moment.js, например. Сложность употребления методов DOM (в которой, впрочем, повинен не язык JavaScript, а браузеры и их разнобой) преодолевается с помощью jQuery. И так далее. Это входит в привычку у программистов. Читать дальше →
В современном вебе используются две основные технологии определения возможностей браузера: (а) распарсить юзер-агент, определить версию браузера и писать в коде свитчи по версии браузера; (б) пытаться определять поддержку фич путём проверки нужных полей / вызовов нужных методов. Исторически сложилось так, что второй вариант считается более true, и именно его реализуют все современные проекты. Достаточно сказать, что этим путём идёт jQuery. И, вроде бы, аргументация-то правильная: (а) не нужно хранить базу регулярок, (б) если в каком-то браузере появляется новая фича, она начинает работать автоматически без изменения кода, (в) неизвестные (экзотические, новые) браузеры будут работать без дополнительных телодвижений, (г) если у пользователя подменён юзер-агент, то код всё равно будет работать. Это всё хорошо и правильно, но только для небольших проектов. И вот почему
Отписаться от этой рассылки