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

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

Всех программистов, которые добиваются успеха в мире разработки ПО, отличает один общий признак: они больше всего заботятся о качестве создаваемого программного обеспечения. Это — основа для них. Потому что они являются профессионалами своего дела. В этой книге леген-дарный эксперт Роберт Мартин (более известный в сообществе как «Дядюшка Боб»), автор бестселлера «Чистый код», рассказывает о том, что значит «быть профессиональным програм-мистом», описывая методы, инструменты и подходы для разработки «идеального ПО». Книга насыщена практическими советами в отношении всех аспектов программирования: от оценки проекта и написания кода до рефакторинга и тестирования. Эта книга — больше, чем описание методов, она о профессиональном подходе к процессу разработки.

Дошли руки до книги Чеда Фаулера «Программист-фанатик».

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

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

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

Хотелось разобраться, что вообще в себя включает процесс создания архитектуры программы, какие задачи при этом решаются, какие критерии используются (чтобы правила и принципы перестали быть всего лишь догмами, а стали бы понятны их логика и назначение). Тогда будет понятнее и какие инструменты лучше использовать в том или ином случае.

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

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

Содержание

1. Что такое тензор и для чего он нужен?
2. Векторные и тензорные операции. Ранги тензоров
3. Криволинейные координаты
4. Динамика точки в тензорном изложении
5. Действия над тензорами и некоторые другие теоретические вопросы
6. Кинематика свободного твердого тела. Природа угловой скорости
7. Конечный поворот твердого тела. Свойства тензора поворота и способ его вычисления
8. О свертках тензора Леви-Чивиты
9. Вывод тензора угловой скорости через параметры конечного поворота. Применяем голову и Maxima
10. Получаем вектор угловой скорости. Работаем над недочетами
11. Ускорение точки тела при свободном движении. Угловое ускорение твердого тела
12. Параметры Родрига-Гамильтона в кинематике твердого тела
13. СКА Maxima в задачах преобразования тензорных выражений. Угловые скорость и ускорения в параметрах Родрига-Гамильтона
14. Нестандартное введение в динамику твердого тела
15. Движение несвободного твердого тела
16. Свойства тензора инерции твердого тела
17. Зарисовка о гайке Джанибекова
18. Математическое моделирование эффекта Джанибекова

Введение

Это было очень давно, когда я учился классе в десятом. Среди довольно скудного в научном плане фонда районной библиотеки мне попалась книга — Угаров В. А. «Специальная теория относительности». Эта тема интересовала меня в то время, но информации школьных учебников и справочников было явно недостаточно.

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

Всем привет.

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

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

Для всех, кто хотел разобраться с Lua (скриптовый язык для разработки игр и не только, список), но никак не находил времени, Tyler Neylon приготовил небольшой подарок:

http://tylerneylon.com/a/learn-lua/

Посвящается всем, кто предпочитает один большой список из говорящих самих за себя сниппетов кода (с небольшими комментариями к 95% case'ов) длинным мануалам с огромной иерархией. Очень удобно для тех, кто уже умеет программировать и просто хотел бы разобраться с новым для себя языком. Весь «мега-сниппет» на английском, но примеры несложно читаются.

P.S. А для всего остального есть Hyperpolyglot.

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

На выходе бизнес, в первую очередь, хочет получить квалифицированных сотрудников — «спецназовцев» от мира тестирования. С какими проблемами мы сталкиваемся?

Проблемы при организации обучения

1. В компании могут отсутствовать тренеры как таковые

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

Много времени прошло с момента появления AngularJs (в масштабах веб-технологий конечно). Сейчас в интернетах есть огромное количество постов восхваляющих этот фреймворк до небес, что это манна небесная не иначе, а критики не так уж и много как он того заслуживает. Но такие статьи уже потихоньку начинают появляться, и меня это радует, надеюсь индустрия переболеет ангуляром так же, как переболела MooTools, Prototype, %какой-нибудь новый язык под JVM%, %другая-супер-революционная-технология%. Не знаю почему, но в IT-области такие революционные технологии, которые поднимают шум, а потом пропадают, появляются довольно часто. Хороший разработчик должен уметь отличать очередную модную технологию, от работающего инструмента. И для этого очень важно критически смотреть на вещи. Моя статья — это компиляция самых весомых выводов из других статей, и моих личных умозаключений. Ангуляр создает хороший вау-эффект, когда видишь его впервые: «ух ты, я написал ng-repeat, и реализовал эту логику одними тегами и все само обновляется!», но как только приходится реализовывать реальные приложения, а не очередной TODO-лист, то все становиться очень печально. Сразу хочу сказать, что фреймворк я знаю хорошо, даже больше чем мне хотелось бы его знать, я программировал на нем в течении 2 лет. И для следующего проекта я его точно не выберу, и это хорошо, все мы учимся на ошибках. Так что же не так с ангуляром? Тут нет однозначного ответа, слишком много разных недостатков, которые создают такой облик фреймворку. Если одним словом – непродуманная архитектура. Под катом я привожу конкретику, так что устраивайтесь поудобнее. ДА НАЧНЕТСЯ ХОЛЛИ ВАР!

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

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

“Да потому что я постоянно этим занимаюсь” — Иван Селиховкин (selikhovkin) в ответ на вопрос, почему мы будем записывать видео именно на эту тему.

После публикации бесплатного курса “Практический PMBoK за 2.5 часа” мы получили массу вопросов про конкретику от тех, кто курс посмотрел, и немало вопросов-сомнений от тех, кто курс не смотрел и вообще сомневается, что курс на 2.5 часа может содержать что-то полезное.

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

Поэтому периодически, когда выдается свободная минутка, занимаемся углублением: развиваем конкретные темы, говорим про инструменты и стараемся ответить на возникшие вопросы. В прошлом видео при помощи Ивана Селиховкина (selihovkin) разбирались с заказчиком. В сегодняшнем видео решили углубиться в алгоритм входа в уже существующий проект:



7 последовательных шагов, которые должен пройти менеджер от своего “медового месяца” к выводам о том, что делать с проектом дальше.

После прошедшего PM-Weekend удалось поймать selikhovkin и попросить записать несколько видео по самым популярным вопросам про управление проектами. Сегодня — первое видео:

10 ответов на вопросы про работу с заказчиком

В рамках видео Иван тезисно раскрыл следующие вопросы:

1. Как заинтересовать бизнес в повышении зрелости системы управления?
2. Методы по формированию ожиданий у заказчика по проекту и их использование
3. Как понять, что хочет заказчик?
4. Как удерживать заказчика от раздувания требований?
5. Как научить заказчика доверять разработчику?
6. Какие методики/методологии ведения проектов и общения с заказчиком существуют?
7. Саботаж сотрудников заказчика (как бороться)?
8. Как сообщить заказчику, что проект идет не по плану, какие фразы использовать, как сгладить впечатление?
9. Особенности работы с гос.заказчиками
10. Что делать менеджеру на проекте, который заказчик пускает на самотек?

Довольно частый запрос от коллег-менеджеров, который приходится слышать: как повысить ответственность человека?

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

Однако, в жизни все сложнее… Приходится заниматься занудными уточнениями: а сейчас люди как работают? — Ну… безответственно.

Хм, яснее не становится. Хочется ехидно уточнить: “в смысле, бросают жен и детей?”, но в реальности, начинаешь разбираться.

В прошлом видео мы попросили нашего Ивана Селиховкина (selikhovkin) рассказать, что по шагам нужно делать, когда тебе достается чужой ношеный уже какое-то время идущий проект. В этот раз, как и обещали, о проектах, которые начинаются с нуля. 10 шагов, которые хорошо бы пройти в рамках планирования проекта:



Чем планирование софтверных проектов похоже на написание книги, как гуры экспертного управления планировали бы написание продолжения “Войны и мира”, и что такое метод оценки трех П — обо всем этом в новом видео.

В данной статье я хочу рассказать начинающим Java разработчикам, как написать простое веб приложение, используя популярный фреймворк Spring Framework.

При разрабокте приложения мы будем использовать утилиту Ant для автоматизации действий и изучим, как писать простой тест с помощью библиотеки JUnit. Весь код будем писать в Eclipse IDE.

Статья написана на основе первой части руководства «Introduction to Spring MVC». Вам достаточно иметь лишь общее представление о Spring, чтобы прочитать статью с пользой.

Так что милости просим :)

Добрый день! Меня зовут Антон Щастный.

Это моя очередная статья, посвящённая разработке веб приложений на Java. Хочу предложить вам сделать небольшую систему учёта клиентов, написанную с использованием фреймворка Spring и библиотеки Hibernate.

Что будет в приложении:

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

Что будем использовать:

• веб фреймворк Spring MVC,
• фреймворк Spring Security,
• ORM библиотеку Hibernate,
• MySQL в качестве СУБД.

Инфраструктура:

• редактор SpringSource Tool Suite,
• сборщик проектов Maven,
• система логгирования Log4j,
• постоянное подключение к интернету.

В моей предыдущей статье о Spring MVC был упущен ряд моментов по использованию аннотаций в Java-коде и применению Maven для сборки проекта. В данной статье я попытался исправить упущение.

Цель статьи – показать начинающим веб разработчикам совместное использование различных технологий платформы Java.

Сейчас почти в каждой статье про web 2.0 и стартапы среди рекомендаций можно увидеть совет: бросьте долгие раздумья и пред-проектную документацию — делайте проект! И очень часто этот совет воспринимается буквально, первые строчки кода появляются еще до того, как идея окончательно сформируется. Что в итоге? А в итоге ядро системы за весь период разработки переписывается раз по 15, не говоря уже о фронтенде. Как следствие проект который был задуман как 1-2х месячный растягивается на пол-года — год. А код превращается в сборище багов.

Что же сделать что-бы этого избежать и при этом не заниматься планированием по пол-года?

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

В отечественном IT я часто наблюдаю следующую картину: тимлидом часто становился лучший (?) разработчик из команды (aka 23-летний сеньор). А чтобы стать руководителем проекта (project manager) иногда достаточно просто знать английский и «павэрпойнт» на уровне пользователя. Это реалии отечественного аутсорсинга и с этим нужно как-то жить.

В итоге часто получается как-то так:

Потому что на десять сеньоров по статистике девять тупят.