Веб-разработка *

КДПВ

Вечерело

Мы с товарищем, сделали простенький тест (github) на проверку доступности data-uri в браузерах. Выглядит он следующим образом:



В textarea javascript'ом вставляется navigator.userAgent. В этот момент я не знаю, что меня стукнуло в голову, но вместо DOMContentLoaded, я написал . По-быстрому проверив корректную работу в десктопных браузерах и на нескольких мобильных устройствах, подключённых к интернету через wi-fi, мы успокоились и разошлись по домам.

Солнце продиралось сквозь занавески

Утром, в полупустом вагоне метро, я как всегда открыл браузер на своем телефоне, на котором со вчерашнего вечера была открыта тестовая страничка. Сказать, что я удивился, когда я не увидел вывода userAgent внутри textarea — ничего не сказать.

Добравшись до компьютера, решил потратить немного времени на поиск проблемы. Запустив страничку на десктопе и в эмуляторе, я ничего не заметил. Открыл на телефоне. Чудеса! Всё работает.

Увидев включённый значок wi-fi, я начал догадываться о причинах проблемы. Я отключил wi-fi, подключил телефон к компьютеру и начал дебаг с помощью веб-инспектора десктопного сафари.

Недавно написал свой велосипед и выложил его на хабре. Вот он: «Простейший Connection pool без DataSource в Java». Статья не из самых удачных, только прошу больше не минусовать. Итак, чтобы не повторять такие ошибки самому и, возможно, предостеречь кого-то от таких ошибок, решил перевести статью «Seven Things You Should Never Code Yourself» достаточно известного в среде open-source деятеля IT-области — Andy Lester'а. Итак, кому интересно, прошу под кат.

Исповедь 1

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

Весь мой опыт программирования складывается из университетских работ и пары лет пребывания в различных компаниях. Критикующие меня люди неоднократно говорили мне, что в целом я разбираюсь в теме, так что я далеко не клинический случай, как можно было подумать. Однако, очевидно, я выработал совсем не те программистские привычки (как минимум, на взгляд работодателя) и мне нужно срочно изменить их. Везде, где бы я ни работал, мои решения, использующие иерархии мелких классов с делегированием поведения, признавались плохими. Говорят, будто так и надо писать, но это не так. Потому что всё это «как надо» может стоить мне работы.

К сожалению, давно пропали топики-ссылки, но иногда бывают крайне занимательные вещи из первых рук. Рекомендую пост Анатолия Воробея (работает разработчиком в «Гугле»).

В видеоформате MP4 (стандарт MPEG-4) есть возможность записать «время создания» любого потока данных, с помощью специальной метки. Значение этой метки в стандарте: количество секунд, прошедших с 1 января 1904 года, или так называемое «время по эпохе макинтоша», потому что маки первыми стали использовать такой отсчет времени. Меж тем, в современных серверах намного проще иметь дело с «временем по эпохе Юникса», а именно количеством секунд, прошедших с 1 января 1970 года. В результате этого, во множестве программ, которые работают на Линуксе или других юниксовских операционных системах, есть кусок кода, который выглядит примерно так:

• получить «время сейчас по юниксу»;
• добавить разницу между временем по юниксу и временем по макинтошу — это некая константа;
• полученное «время сейчас по макинтошу» записать в файл MP4, который мы создаем.

Чему равна константа «разница между временем по юниксу и временем по макинтошу»? Она равна в точности числу секунд, прошедших между 1 января 1904 и 1 января 1970. Это 66 лет, из которых 17 были високосными (проверьте, если не доверяете мне). Всего дней получается: 66 * 365 + 17 = 24 107, а секунд, учитывая 86 400 секунд в сутках: 24 107 * 86 400 = 2 082 844 800. Это правильное значение константы.

Всем привет!

Я работаю над фронтендом огромного проекта — поисковой выдачи Яндекса. И у нас, как и у любого другого большого веб-проекта, есть огромное количество css-кода и немаленькая команда, которая с ним взаимодействует.

Когда много людей, используя разные инструменты, пишут и редактируют css, со временем этот css может получиться очень запутанным, неконсистентым и в целом начинает выглядеть плохо. Например, кому-то удобнее писать вендорные префиксы в одном порядке, кому-то — в другом, кто-то ставит кавычки вокруг url, кто-то — нет, а кто-нибудь фикся срочную багу к релизу мог бы, к примеру, написать position: relative в начале блока свойств, незаметив что где-нибудь внизу между color и box-shadow, уже есть position: absolute, и долго гадать, почему у него ничего не работает.



Но несмотря на то, что все пишут код по-разному, у нас в репозитории идеальный порядок: css-код полностью консистентен, и прекрасно выглядит. Весь.

Как мы этого добились, можно прочитать под катом.

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

DC.js

Библиотека позволяет создавать великолепные многоуровневые/масштабируемые кроссплатформенные графики и диаграммы с моментальным перерендерингом при пользовательском взаимодействии. За процесс визуализации отвечает знаменитая d3.js, а за анализ многомерных наборов данных crossfilter.js. Кстати кроссфильтр — проект небезызвестной компании Square.

chart.renderlet(function(chart){
    // smooth the rendering through event throttling
    dc.events.trigger(function(){
        // focus some other chart to the range selected by user on this chart
        someOtherChart.focus(chart.filter());
    });
})

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

Так, Mac OS X впервые была показана под кодовым названием Rhapsody в 1997 году, но выпуск первой версии состоялся только спустя четыре года. Выпуск Windows Vista планировался на 2003 год как второстепенное обновление между Windows XP и полноценной новой версией, но ждать пришлось целых три года.

Однако оба упомянутых примера – ничто в сравнении с проектом Xanadu, который в конце апреля был без лишней помпы представлен на мероприятии в калифорнийском Чемпенском университете. Разработка Xanadu началась 54 года назад – в 1960 году. Это самое долго разрабатываемое ПО в истории.

Решил собрать сервисы, которые могут быть полезны веб-разработчикам и дизайнерам. Буду рад, если кто-то найдет для себя полезный сервис. Осторожно, под катом куча картинок!

Каждый программист — проектировщик API. Хорошие программы состоят из модулей, а протокол взаимодействия модулей — это тоже API. Хорошие модули используются повторно.

API — это большая сила и большая ответственность. У хорошего API будут благодарные пользователи; поддержка плохого превратится в кошмар.

Публичный API — не воробей, опубликуешь — не уберешь. Есть только одна попытка сделать все правильно, поэтому постарайся.

API должно быть легко использовать, но сложно использовать неправильно. Сделать что-то простое с помощью такого API должно быть просто; сложное — возможно; сделать что-то неправильно должно быть невозможно, или, по крайней мере, трудно.

API должен описывать сам себя. Изучение кода на таком API не вызывает желания читать комментарии. Вообще, комментарии редко нужны.

Перед разработкой API собери требования с долей здорового скептицизма. Осознай общие задачи и реши их.

Оформляй требования как шаблоны использования API. Сверяйся с ними в процессе проектирования.

update (10.06.2014): Алексей опубликовал отчет ФБК за 2013й год, сослался на этот пост и обещал доделать систему в 2014м. И это круто. Хабр — сила.

Введение

Я должен был написать этот пост примерно год назад. В конце 2012го года, будучи директором Фонда Борьбы с Коррупцией, я, в числе других сотрудников фонда, организовывал второй фандрайзинг на РосПил, где мы сделали ряд обещаний касающихся разработки информационной системы Фонда, за которые давно следовало отчитаться.

РосПил — это первый действительно успешный общественный проект в России, логотип которого, кстати, придумал анонимный пользователь Хабра, а сайт на руби также бесплатно сделал Павел Сенько. Суть проекта — проведение формальных юридических расследований подозрительных закупок с zakupki.gov.ru путем обращения в госорганы и придания гласности результатам.



Одна из идей которую я активно продвигал в Фонде — большая прозрачность и автоматизация работы юристов. Хотелось отказаться от использования гуглдоков для публикации документов, вместо этого загружая их в специальную систему, где будет отслеживаться связь запросов и ответов на них, а также принадлежность документов одному «делу». Таким образом, не получится забыть ни о каких делах, всегда будет видно, что всё доведено до конца и не брошено. Появится место, где можно в удобном и доступном виде посмотреть на деятельность всего Фонда и каждого юриста в исторической перспективе.

Именно поэтому в просьбу денег (рабочая ссылка на полную презентацию, см. слайд 25) было включено создание такой информационной системы. А также обещание раскрыть ее для других юристов и организаций. Фандрайзинг был успешен, собрали более десяти миллионов рублей и такую систему ФБК действительно разрабатывал под моим руководством в качестве директора фонда и менеджера продукта. Порядка миллиона рублей на это было потрачено и я чувствую себя обязанным официально поделиться сделаным на общественные (ваши) деньги. Весь код и дизайны лицензированы по открытой лицензии Creative Commons (Attribution-NonCommercial-ShareAlike 4.0 International), что отражено в договорах с Фондом подписанных Алексеем.

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

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

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

Мы решили провести небольшой эксперимент — пригласить шесть детей от шести до десяти лет и показать им гаджеты из недалёкого прошлого.

Хочу поделиться двумя примерами того, как западные компании уважительно относятся к деньгам клиентов и не стараются их оставить себе в случае очевидных ошибок клиентов. Этого очень не хватает русским компаниям, особенно сотовым операторам, которые дошли уже до того, что при неправильном вводе USSD-команды показывают «анекдот» и списывают от 30 рублей.

Сегодня в мастер ветку Django приняли совершенно дикий с точки зрения логики pull request.

Во всем проекте, включая код, общепринятые термины master/slave были изменены на leader/follower.

Вот как обосновал это автор патча fcurella:

Документация и некоторые тесты содержат ссылки на master/slave конфигурацию БД.
Несмотря на то что эта терминология использовалась достаточно долгое время, эти термины могут нести расистcкую подоплеку для пользователей.
Этот патч заменяет все использования master и slave на leader и follower.

Видимо Мизулина это достаточно интернациональный термин, а не только российский.

Это случилось: Хабр получил новый дизайн в стиле остальных ТМ-продуктов.



Вообще-то я люблю перемены, и редизайн привычных вещей вызывает в первую очередь оптимизм. Это как перестановка мебели в квартире: обстановочку освежать надо. Но помимо приятного чувства новизны некоторые изменения вызывают вопросы. Понятно, что Хабр уже не торт и мы всегда будем помнить его тёплое ламповое старое лого, но я хочу поговорить про то, что можно оценить вполне объективно — про юзабилити нового хабрадизайна.

13 мая прошла презентация новых возможностей продуктов 2ГИС. Про некоторые из них мы сегодня уже говорили, настал черёд рассказать про остальное.

На днях Даниэль Штенберг, один из участников группы HTTPbis IETF, которая ведёт разработку протокола http2, опубликовал в своём блоге крайне интересный документ «http2 explained». Небольшой PDF-документ на 26 страницах весьма доступным языком рассказывает о предпосылках и деталях реализации протокола http2.

Как мне кажется, на сегодняшний день это одно из самых лучших разъяснений о том, что такое протокол http2, зачем он нужен, как он повлияет на веб-разработку и какое будущее ждёт Интернет в связи с его появлением. Думаю, что всем людям, причастным к веб-разработке и веб-строению, информация будет полезна, ведь ожидается, что стандарт http2 будет принят уже в июне этого года после завершающей встречи группы HTTPbis в Нью Йорке.

И снова подборка статей, релизов и интересных проектов о python и близлежащих технологиях. Сегодня будут Haskell, ниндзя, клики, кокаин — в общем все что нужно для хорошего шоу.

Не перестаю благодарить owlman75 за иллюстрацию. Даже отпуск ему не помеха. И большое спасибо за новости, которые вы присылаете — они мне очень помогают верить в то, что проект нужен не одному мне.

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

Наверняка вам доводилось попадать в такую ситуацию: заходите в какое-нибудь учреждение (почта, банк, больница, кассы и т. п.), где для достижения ваших целей необходимо предъявить паспорт. И вроде очередь-то небольшая, всего 5 человек, но ждать придётся очень долго, ведь тётя Маша тратит по несколько минут на внесение данных с каждого паспорта в компьютер. Вам остаётся только наблюдать, как её указательный палец не спеша планирует над клавиатурой в поисках очередной клавиши.

Мы были озадачены такой печальной ситуацией в современном обществе и написали программку PassportVision, которая умеет распознавать данные с разных документов и отдавать результат пользователю в удобной форме. Задача оказалась совсем не такой простой, как может показаться на первый взгляд: в ходе работы над проектом мы узнали очень много нового про отечественные документы, компьютерное зрение и пользовательские интерфейсы. Голова уже полна новыми идеями о дальнейшем развитии программы, но мы решили найти время, чтобы поделиться опытом и полученными знаниями.



Сегодня в выпуске:

• Популярные заблуждения о паспортах
• Немного об используемых технологиях
• Наш подход к интерфейсу
• Как лучше всего отдать данные пользователю

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

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

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

Услышав о невероятном эксперименте Дженнифер Девальт, которая решила изучить программирование, создав 180 сайтов за 180 дней, я отважился испробовать сходную тактику: работать над побочными проектами каждый день.


Иллюстрация Стивена Резига

Публикация будет интересна людям, работающим в “хардверных” стартапах, а особенно если основатели имеют “софтверное” прошлое.
У большинства людей, кто значительную часть своей карьеры проработал в ”софтверной” индустрии и хочет создать “хардверный” продукт, может сложиться впечатление, что путь от идеи к прототипу, такой же как при разработке мобильного приложения или вебсайта: спроектировали, нарисовали дизайн, реализовал прототип. В принципе, эти фазы сохраняются и при разработке устройств, но фаза воплощения прототипа может принести вам немало сюрпризов и иметь несколько итераций. Что и случилось при создании нашего первого продукта LaMetric.