Думаю, многие из вас знают, что сейчас существует обилие различных языков (или инструментов), которые позволяют писать код компилируемый в JavaScript. Это CoffeeScript, Dart, GorillaScript и другие (довольно большой список можно найти здесь). Недавно я решил познакомиться с одним из представителей этого списка — языком программирования под названием TypeScript.

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

Если вам это интересно — пожалуйста, заходите под кат.

Предлагаю читателям «Хабрахабра» перевод статьи «Mastering Composer – Tips and Tricks» за авторством Bruno Skvorc.



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

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

Перевод поста Malte Lenz "Machine Gun Jetpack: The Real Physics of Improbable Flight".
Скачать файл с моделями, рассмотренными в посте, можно здесь здесь.
Выражаю огромную благодарность Кириллу Гузенко за помощь в переводе.

---

Можно ли летать с помощью автомата, используя реактивную силу, возникающую при выстрелах? Этот вопрос был задан в статье What if? Рэндалла Манроу “Machine Gun Jetpack” (перевод поста на русский язык). Оказывается что можно, потому что некоторые автоматы создают достаточную силу для того, чтобы поднимать свой собственный вес, а может даже и немного больше. В этом посте я исследую динамику стреляющих вниз автоматов, а так же действующие при этом силы, порождаемые скорости и то, на какую высоту можно будет подняться таким способом. Я так же продублирую предупреждение из статьи: пожалуйста, не повторяйте этого дома. Для этого есть программные среды для моделирования.

В 2000 году я был большим фанатом PHP. Я начал пользоваться им сразу после официального выхода версии 4.0 в апреле. В то время кроме него было всего 4 альтернативы для создания веб-сайтов.

1) C – слишком сложный для часто меняющегося проекта. Компиляция занимала много времени, было мало свободных инструментов, а платные не влезали в мой бюджет. Слишком многословный. Управление зависимостями было сложным делом.

2) Java – лучше, чем С, но всё ещё многословный и долго компилирующийся. Управление зависимостями было сложным делом.

3) Perl – почти так же хорош, как PHP, только без системы управления пакетами. На CPAN был набор модулей на все случаи жизни, но их надо было скачивать и устанавливать. Управление зависимостями было сложным делом.

4) ASP – почти так же хорош, как PHP, только это был инструмент от Microsoft, и его использование засосало бы меня в их дорогой мир.

Для трёх позиций я написал: " Управление зависимостями было сложным делом". Для меня это был ключевой момент PHP. Его философия была «всё в одном». Таких, как сейчас, систем управления пакетами тогда не было. Сейчас есть удобные штуки типа Bundler для Ruby и Leiningen для Clojure. Но не в 2000-м. Даже системы управления пакетами в Linux стали лучше с 2000 года. А система «всё в одном» решала проблемы управления пакетами в PHP. Но теперь это преимущество не имеет значения.

Всего несколько часов появился followphpdevs.com, позволяющий одним кликом зафолловить 72 известных PHP разработчика, и уже успел распространится по сети. В список вошли авторы фреймвоков, частые спикеры и те, кто работает над самым языком. Из жителей хабра там можно найти меня и @sam_dark.

Даже если вы не используете Twitter в списке, все равно можно найти много интересных блоггеров.

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

Как грибы растут стандарты, фреймворки, развивается и становится всё слаще синтаксис, растут разнообразные инструменты.

И это здорово!

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



Попробуйте пройти несложный тест и определить — не мамонт ли Вы в мире PHP? Не грозит ли Вам, как специалисту, вымирание в ближайшее время?

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

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

Воздействие vs Абстракция

Первое, что вы должны сделать — пойти почитать пост “Abstraction or Leverage” от Майкла Найгарда. Это отличная статья.

Если же у вас мало времени, основная суть поста состоит в том, что части кода (функции, классы, методы и т.д.) могут предназначаться либо для абстракции, либо для воздействия. Разница в:

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

Суффиксное дерево – мощная структура, позволяющая неожиданно эффективно решать мириады сложных поисковых задач на неструктурированных массивах данных. К сожалению, известные алгоритмы построения суффиксного дерева (главным образом алгоритм, предложенный Эско Укконеном (Esko Ukkonen)) достаточно сложны для понимания и трудоёмки в реализации. Лишь относительно недавно, в 2011 году, стараниями Дэни Бреслауэра (Dany Breslauer) и Джузеппе Италиано (Giuseppe Italiano) был придуман сравнительно несложный метод построения, который фактически является упрощённым вариантом алгоритма Питера Вейнера (Peter Weiner) – человека, придумавшего суффиксные деревья в 1973 году. Если вы не знаете, что такое суффиксное дерево или всегда его боялись, то это ваш шанс изучить его и заодно овладеть относительно простым способом построения.

Главным рабочим инструментом увлечённого своим делом программиста является ноутбук. Ты не привязан к конкретному офисному столу, да и вообще к офису, если на то пошло. Ноутбук для программиста и рабочее место, и центр развлечений, и окно в мир сеть. Но такая свобода имеет один недостаток: ноутбук вещь не маленькая, в карман не положишь. Можно, конечно, носить его в сумке через плечо, но это не слишком удобно: надо придерживать рукой, поддергивать соскальзывающий ремень, да и сама сумка получается широкой и жёсткой. В общем, чемодан без ручки. Совсем другое дело — рюкзак. Руки свободны, нагрузка распределена равномерно и гораздо комфортнее, ничего не болтается сбоку. Да и ноутбук защищён от всяких коллизий не в пример лучше. Неудивительно, что рюкзаки сегодня столь популярны среди всех слоёв населения, не только среди программистов. А уж в дальних поездках и перелётах рюкзаки вообще вне конкуренции. Поэтому стоит уделить особое внимание выбору модели, которая удовлетворяет всем вашим нуждам, эстетическому вкусу и анатомическим особенностям. Так что если вам приходится носить ноутбук, а ваш текущий рюкзак надоел или чем-то не нравится, или вы только подумываете перейти на рюкзак, то рекомендуем посмотреть эту подборку. Возможно, подберёте для себя интересную модель.

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

IT-интерфейсы часто растут из физических. Например, вот аппаратные чекбоксы:



Вообще, лучший же пример правильного инженерного интерфейса – это гранёный стакан.

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

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

Обычный кран с горячей и холодной водой очень жесток к пользователю. В идеале его интерфейс решает три основные задачи:

• Позволяет выбрать напор воды.
• Позволяет выбрать температуру воды.
• И защищает систему от гидравлического удара.

Вот тут вы можете узнать пару своих знакомых кранов:



А это — очень страшный автомобильный диод, по нему только вперёд:



Итак, если вам интересно продолжение про интерфейсы в реальном мире – заходите в пост. Осторожно, трафик.

Введение

В качестве введения я расскажу кратко о хак квесте Ratazana CTF. Его организовали специалисты из ЦИС (Центр Информационной Безопасности), представительство которого располагается в г. Бишкек Киргизия. Это первый отлично организованный хак квест. Он был прост и интересен и скорее всего служил так называемой отправной точкой (так сказать организаторы хотели прощупать уровень участников).

Коротко о квесте

По легенде квеста компания VideoCorp столкнулась с утечкой исходных кодов ее продукта, в результате чего EvilCorp выпустила очень похожу версию ПО раньше, чем компания VideoCorp, что привело к убыткам компании и потере хороших клиентов. Нужно было найти крота и собрать доказательства. На весь квест отводилось 7 дней. В квесте 8 миссий. Итак, приступим!

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

Итак, представим себе, что есть два программиста. Один из них умный, прочёл кучу статей на Хабре, знает каталог GoF наизусть, а Фаулера — в лицо. Другой же делает всё просто. Первого будут звать, например, Борис Н., а второго — Маркус П. Само собой, имена вымышленные, и все совпадения с реальными людьми и программистами случайны.

Итак, к ним обоим приходит проектный менеджер (если в вашей вселенной PM не ходит сам к программистам, назовите его как-то иначе, например BA или lead, сути это не изменит) и говорит:
— Ребята, нам нужно, чтобы делался хлеб.

Именно так, «делался», без уточнения способа производства.

Как же поступят наши программисты?

Имеется страшилка, обладающая невероятным количеством подчеркиваний, лямбд и чрезвычайно редкой функцией __import__:



Что за зверь и что он делает?

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

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

И тут-то меня ждало разочарование: я не был способен написать ничего кроме hello world-a. Т.е. я примерно представлял себе, как написать какую-нибудь консольную утилиту типа find или вроде того, — но первая же встреча с IO разрушала все мои представления. Библиотек для Haskell вроде бы много, а документации по ним почти совсем нету. Примеров решения типовых задач тоже очень мало.

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

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

Для самых нетерпеливых: исходники здесь.

Бен Кэменс обнаружил, что в выпадающем списке Shop by Department на сайте «Амазон» ховер-эффект происходит очень быстро, абсолютно без какой-либо задержки. Тем самым происходит нарушение старого, выработанного ещё в 90-х годах прошлого века правила: перед отображением пункта подменю необходим так называемый гистерезис, запаздывание.



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

MySQL — одна из самых распространенных СУБД. Ее можно встретить повсюду, но наиболее часто она используется многочисленными сайтами. Именно поэтому безопасность базы данных — очень важный вопрос, ибо если злоумышленник получил доступ к базе, то есть большая вероятность, что он скомпрометирует не только ресурс, но и всю локальную сеть. Поэтому я решил собрать всю полезную инфу по взлому и постэксплуатации MySQL, все трюки и приемы, которые используются при проведении пентестов, чтобы ты смог проверить свою СУБД. 0day-техник тут не будет: кто-то еще раз повторит теорию, а кто-то почерпнет что-то новое. Итак, поехали!

Аннотация

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

С PHP дело обстоит сложнее: уже писали про статический анализ PHP кода, но в целом инструментарий тут гораздо беднее, и динамическая природа языка делает процесс разработки-тестирования сложнее. Для сравнения, в той же Java компиляция проекта сама по себе помогает найти ошибки, а в PHP типизация слабая, поэтому даже тесты могут пропустить ошибки.