Я закончил августовскую сессию курса Learning How to Learn (LH2L) на Coursera и хотел бы поделиться впечатлениями с хабрасообществом, а также дать несколько советов и предостеречь.

Постулируемая цель курса — рассказать об эффективных методах обучения. В том числе и самообразования.

Курс проходил с 1 августа по 1 сентября. Лекторы — Barbara Oakley (подавляющее большинство записей) и Terence Sejnowski (появлялся изредка). К курсу прилагался опциональный учебник «A Mind for Numbers», который авторы старательно рекламировали.

Содержание курса:

Видео про 8 способов противостояния формуле нужды оказалось неожиданно популярным, набрав 8,000 просмотров за два дня. Мы решили продолжить тему.

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

Мы отобрали 10 самых любопытных, на наш взгляд, вопросов в этой теме и снова заперли в студии Дмитрия Коткина, руководителя Санкт-Петербургской школы переговорщиков ШиП и нашего хорошего друга, чтобы он рассказал, что конкретно делать:



10 реальных ситуаций, которые удалось осветить — под катом:

Всем привет!

Уже слышали про Bigdata? Ну да, веб растет, данных становится больше и их нужно держать под контролем и периодически анализировать. Базы данных — лопаются под нагрузкой, реляционная теория не совсем справляется с задачей, нужно решение. Маркетинг активно давит сверху, а железо острыми углами — снизу и попахивает суицидом.

В этом посте постараюсь дать конкретные работающие рецепты и куски кода с краткими теоретическими выводами, как же обрабатывать >=терабайты в >=1000 потоков на PHP. Чтобы можно было взять и решить задачу, не теряя времени и не забивая голову теорией.

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

Итак, вы хотите разрабатывать игры, но у вас никаких возможностей? Не правда, возможность есть всегда!

Самый простой и логичный ответ: учи язык и разрабатывай. А с учетом развития индустрии, есть целый ряд мастеров типо gamemaker, которые значительно облегчат работу.

Что же делать, если программирование — не ваш конек? Ну, например у меня не сложилось, кодинг — не мое. Языки учил, основы алгоритмизации знаю, но не лежит душа, не интересно.

А такой мой жизненный принцип — работа должна быть интересной!

Как же поступать в таком случае. Ответ, опять же, очень прост:

Ищите кого-то, кто сделает это

Ну, все вроде бы логично:

Зарабатывайте денег, нанимайте кого то. А раз логично — надо делать!

Сделал. Потратил кучу денег и времени, делюсь опытом.

Последнее время я часто сталкивался с разработкой на Ruby и Ruby on Rails. О них говорить я не собираюсь. Но после возвращения к PHP кое-чего стало очень не хватать. Одна простая утилита, оказавшаяся отличным помощником для любого разработчика, который использует тесты. autotest запускает тесты на любое изменение в кодовой базе или тестах. Я попробовал поискать в Гугле и на Гитхабе аналог для PHP. Все решения, которые я нашел, были написаны либо на Ruby, либо на серверном JavaScript, либо на bash (хотя позже все же нашел решения и на PHP, которые, тем не менее, мне не понравились по разным причинам). Я являюсь сторонником мнения, что утилиты для разработки на каком-то языке должны быть написаны на нем же. Причин тому много, одна из наиболее значимых лично для меня — это возможность легко и непринужденно вносить какие-то правки и изменения в код самой утилиты (например, когда разработчик утилиты не реагирует на баг-репорт). Руки у меня зачесались, и я попробовал написать свою версию autotest для PHP. Результат можно посмотреть на Гитхабе.

INTRO

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

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

Итак, для начала отвечу на главный вопрос: для чего всё это нужно.
Есть несколько причин.

Тема заезженная до дыр, не спорю… Вероятно, для опытных разработчиков моя статья будет мало, чем полезна. Я бы рекомендовал её к прочтению тем, кто только начал осознавать, что его коду чего-то не хватает, и что он созрел для вникания в это далёкое понятие – «паттерны». По себе помню, что довольно долгое время я путался в шаблонах, иногда даже не понимая, чем один отличается от другого. Именно этот факт стал основой для моей статьи. Примеры в ней не будут реальными. Они будут абстрактными и максимально простыми. Однако я постараюсь все примеры держать в едином контексте, чтобы можно было наглядно видеть отличия их использования в одной и той же ситуации. Я не буду нагружать классы лишним функционалом, чтобы можно было понять, какая именно часть кода имеет непосредственное отношение к шаблону. Главными героями примеров станут Factory (фабрика) и Product (продукт, производимый этой фабрикой). Возьмём это отношение за отправную точку. Возможно, в некоторых примерах это будет не очень уместно, но зато очень наглядно…

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

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

Первые шаги

Первый навигатор появился в 1920 году. В комплекте к устройству Plus Fours Routefinder, похожему на часы, шли карты. Крутить их нужно было вручную.



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

Продолжим разглядывать Symfony CMF, реализующую концепцию платформы для построения CMS из слабосвязанных компонентов. В первой части статьи мы подробно рассмотрели схему хранения и доступа к данным, во второй части нас ждет все остальное.

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

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

Итак. Что у нас по плану после хранения данных?

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

Данный подход популярен среди разработчиков вредоносного кода, так как с одной стороны значительно усложняет анализ исходного кода, а с другой позволяет хранить код в текстовых данных. Например, часть вредоносного кода может загружаться со стороннего сайта, из базы данных, мета-данных jpeg/png/gif или передаваться в запросе к скрипту. Кроме того, часть кода, представленная в виде обычной текстовой строки, может быть легко зашифрована.

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

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

echo "Test"

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

Привет, Хабр.

Так сложилось, что недавно мне в руки попала замечательная книжка Pro PHP, в которой целый раздел посвящен итераторам. Да, я знаю что на Хабре эта тема уже поднималась (и наверняка не раз), но все же позволю себе дописать данную статью, т.к. бОльшая часть примеров в вышеупомянутых статьях достаточно оторваны от реальности. И так — если Вам интересно какую же реальную задачу мы собираемся решать с помощью итераторов — добро пожаловать под кат.

В реальной жизни мы повсюду сталкиваемся с различными контрактами: при устройстве на работу, при выполнении работ, при подписании взаимных соглашений и многими другими. Юридическая сила контрактов гарантирует нам защиту интересов и не допускает их нарушения без последствий, что дает нам уверенность в том, что те пункты, которые описаны в контракте — будут выполнены. Эта уверенность помогает нам планировать время, планировать расходы, а также планировать необходимые ресурсы. А что если и программный код будет описываться контрактами? Интересно? Тогда добро пожаловать под кат!

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

BrowserSync

Я считаю это лучшим Live Reload инструментом. BrowserSync — это: конечно же перезагрузка страницы после изменения исходных файлов в том числе и серверных (PHP, ASP, Rails и др); синхронизация с десктопами, планшетами и смартфонами; синхронизирует между браузерами скроллинг, данные в формах и множество других действий; существует как Grunt и Gulp плагин; доступен на Windows, Linux, MacOS.

npm install -g browser-sync

// Using a an IP based host
browser-sync --proxy "192.167.3.2:8001" --files "app/css/*.css"

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

А ведь работа должна приносить удовольствие, правда? В итоге появилось стойкое желание сменить поле деятельности и переквалифицироваться из стандартного “PHP Developer” в модного “Javascript/Frontend Ninja”.

Нашел подходящую контору, отправил CV, договорился о дате тестового задания. На тот момент я чувствовал себя достаточно подготовленным, всё-таки за плечами неплохое знание Backbone, парочка одностраничных приложений, эксперименты с Canvas, Google Maps, Node.js, Websockets и прочими. В общем было что показать.

Но тестовое задание приближалось и надо было готовиться. Первым делом я загуглил “javascript interview questions” и тут же прифигел. В голове завертелась мысль: “Почему все эти задания настолько оторваны от реального мира?”

У меня достаточно неплохой опыт в верстке — несколько лет.
За это время было многое — и табличная верстка, и собственные фреймворки, и IE6, и адаптивный дизайн, да что угодно — я всегда старался быть рядом с bleeding edge, как говорится.
Больше CSS-фреймворков (привет, бутстрап) и Emmet-а мне нравятся препроцессоры и я расскажу, почему. Возможно, покажется, что моя статья несколько устарела и сейчас все используют препроцессоры как само собой разумеющееся, но, увы, это не так. Недавно я встретил человека, который говорил о том, что ему быстрее писать CSS-код, нежели использовать препроцессоры. Мы долго спорили, на самом деле, ну очень долго, в итоге я решил выложить свои мысли здесь, в одном месте.

Less или Sass?

Ну, на самом деле, это дело каждого. Мне не нравился Sass из-за его медлительности — Less побыстрее выполнялся всегда, в итоге в один момент я решил перейти на Less, но через некоторое время оказалось, что мне не хватает его мощности! Увы, я так и не нашел, как реализовать банальный миксин уровня вот этого.
Но и медлительность Sass не устраивала, но именно в тот момент, когда я хотел обратно вернуться на Sass, но терзался сомнениями, мне посоветовали libsass, а т.к. я использую Grunt — мне было достаточно подключить только grunt-sass (и ничего больше, например, установка Ruby и гемов). Для меня выбор был ясен и с тех пор — только libsass. Мощность самого Sass и с скорость C — что еще нужно?
Stylus я пока не пробовал, как-нибудь потом.

Почему все-таки препроцессоры?

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

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

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

1. Быть элементами дизайна сайта (бекграунды, кнопки и т.д.).
2. Загружаться через специальные модули (например, изображения в фотоальбом).
3. Вставляться через WYSIWYG-редактор CMS (например, в текст статьи).

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

Сначала на помощь приходит реализация Adaptive Images…

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

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

Этап 1 – мало опыта, много энтузиазма (низкий навык, высокая мотивация). Это может быть молодой специалист, получивший первую работу; человек, решивший попробовать себя в новой профессии или профессионал, которого выдвинули на руководящую должность. В общем, любой из вариантов, когда человек только что пришел на новое место, очень хочет добиться успеха, но еще не понимает как это сделать.

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

Любой цифровой фотограф неоднократно встречался с ситуацией, когда флэшка со свежими снимками уже вставлена в слот компьютера или ридера, а места на рабочем диске нет. Это неприятно. Ещё неприятнее, когда два-три часа убито на переписывание предыдущих снимков на оптические диски, а потом выясняется задним числом, что часть файлов на них безнадёжно испорчена. С точки зрения фотографа (и самого искусства фотографии), каждый снимок уникален; потеря его эквивалентна потере мгновения чьей-то жизни, причём для фотографа эти мгновения могут сложиться в весьма чувствительное время: ведь снимок надо сделать, сохранить, обработать, распечатать, показать… Я уже не говорю о чисто материальных потерях, от коллекционных до финансовых, которыми гибель любого снимка чревата для коммерческого фотографа.

О чем это все

Это будет короткий пост. Сначала личная история, а потом как это применить на практике к управлению сотрудниками.
Чисто опыт, никаких теорий.

Во-первых, часто говорят о работе на результате. О людях, ориентированных на процесс или на результат. Соотношение, как говорят, 95% к пяти. Рекомендую всем менеджерам проектов для начала великолепное видео Сергея Котырева в тему. Кстати, горячо рекомендую и другие видео посмотреть — Сергей достиг успеха на непростом рынке и знает, о чем говорит.



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

Глядя в историю выполнения мной тестовых заданий, видятся закономерности, о которых хотелось бы предупредить коллег, потому что такие случаи встречаются регулярно и, скорее всего, независимо от специализации разработок. Например, к таким выводам я пришёл, имея на счету более десятка выполненных в разные годы заданий объёмом 2-5 рабочих дней каждое. А выводы — настолько парадоксальные, что, думаю, вызовут споры и удивление у тех, кто этого не прошёл. Сформулирую основной вывод для начала, а затем покажу обоснования на примерах из практики.

Вывод: (софизм) тестовое задание объёмом более дня с основной целью (поступления на работу) выполнять невыгодно.