Здравствуй хаброчеловек!

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

Привет, Коллективный Разум!

Мы, два студента, при выполнении контрольной работы по предмету «управление качеством» решили провести интернет-опрос. В частности, по измерению, в самом хорошем смысле этого слова, удовлетворенности потребителя. Объектом исследования стал почтовый веб-сервис от компании Яндекс — Яндекс.Почта. По полученным данным будет опубликована соответствующая статья.
А вот и ссылка на лаконичный опрос, ответив на вопросы которого можно удовлетворить студентов на отличненько.
Мы не являемся сотрудниками или конкурентами Яндекса на рынке бесплатной веб-почты.

Хочу начать с того, что за свою деятельность в сфере разработки софта и веб-сайтов я написал более 200 технических заданий (ТЗ). От самых маленьких на 5-7 страниц, до более развёрнутых на 100-150. Среди этих проектов были и такие, которые не нужны были ни заказчикам ни исполнителям, и такие, в которые вкладывалась душа — со стороны всех участников проекта. И что я теперь об этом думаю? А думаю я, что технические задания вообще на…

Вводная информация по управлению рисками

К теме управления рисками я решил обратиться по нескольким причинам:

• недавно я разрабатывал методику и процедуру по управлению рисками в компании, где я работаю (разработка ПО под заказ, аутсорсинг) – соответственно, было перерыто и изучено очень много материалов, информация из которых потом была структурирована и оформлена в отдельный документ, который сейчас используется
• само по себе управление рисками является одной из ключевых активностей на проекте: на мой взгляд одной из самых сложных, но в то же время интересных (из каждого риска и события можно извлечь выгоду)
• как показывает опыт работы в компаниях-разработчиках ПО, управлению рисками выделяется либо очень мало времени, либо ими начинают управлять только тогда, когда они становятся проблемами (что, согласитесь, довольно поздно). Надеюсь, что информация, собранная здесь, подтолкнет интересующихся к дальнейшему изучению темы и внедрению соответствующих практик в работе

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

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

Определение риска

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

Risks are schedule delays and cost overruns waiting to happen (by Peter Kulik)
Risk is the possibility of suffering loss (SEI, Dorofee 96)

Также следует понимать основное отличие понятия риска от понятия проблемы:

• риск это некоторое событие, которое может случиться в будущем и может привести к определенным потерям (снижение качества продукта, перерасходование бюджета, задержка сроков либо полной неудачи проекта)
• проблема же – это событие, которое уже случилось. Риски превращаются в проблемы, если с ними не работать

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

Эти приемы были описаны во внутреннем проекте компании Google «Testing on the Toilet» (Тестируем в туалете — распространение листовок в туалетах, что бы напоминать разработчикам о тестах).
В данной статье они были пересмотрены и дополнены.

Введение

Недавно я осознал, что на Хабре нет ни одной статьи, посвящённой прекрасному фреймворку Bottle, которым, кстати говоря, пользуется не мало людей, поэтому в этой статье я попытаюсь рассказать вам о нем.

Существуют три вида лжи: ложь, наглая ложь и статистика (источник)

Есть такой замечательный жанр — "вредные советы", в котором детям дают советы, а дети, как известно, всё делают наоборот и получается всё как раз правильно. Может быть и со всем остальным так получится?

Статистика, инфографика, big data, анализ данных и data science — этим сейчас кто только не занят. Все знают как правильно всем этим заниматься, осталось только кому-то написать как НЕ нужно этого делать. В данной статье мы именно этим и займемся.


Hazen Robert "Curve fitting". 1978, Science.

Структура статьи:

1. Введение
2. Предвзятая выборка (Sampling bias)
3. Правильно выбираем среднее (Well-chosen average)
4. И еще 10 неудачных экспериментов, про которые мы не написали
5. Играем со шкалой
6. Выбираем 100%
7. Скрываем нужные числа
8. Визуальная метафора
9. Пример качественной визуализации
10. Заключение и дальнейшее чтение

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

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

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


Примерный план (посмотрим по ходу действия) ожидается следующий:

1. Hardware выключателя
2. Тестирование и подготовка
3. Software выключателя
4. «Центр управления»

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

Привет Хабр!

Изначально хотел назвать статью «HTML по ГОСТ`у», но потом выяснилось что у большинства программистов не было предмета «Метрология и стандартизация» и о «стандартизации», «сертификации», «унификации» не все слышали.

В i-Free я много занимаюсь разработкой веб-приложений. А поскольку их много, они разные и работают в разных условиях, то само собой приходится задумываться о стандартизации. Есть такой проект «Пуленепробиваемый HTML5» (http://html5boilerplate.com/), в котором разработчики решили создать идеальный шаблон странички. Он мне очень нравился, и все свои проекты я начинал именно с него. Но, исправляя баг за багом, делая все новые и новые приложения, я пришел к выводу, что многого в нем не хватает. В этой статье я хотел бы рассказать о том, что обычно пропускают при написание страничек и веб-приложений и показать, чем и зачем я прокачал свой шаблон пустой странички.

В подборке сегодня большая статья о том, как делали приложения для Олимпиады в Сочи, как будут работать приложения в Apple CarPlay, как работать с Nokia X разработчикам Android приложений, большое исследование мобильного интернета в России. Ну и пользуясь случаем поздравляю наших любимых дам с прошедшим праздником, а всех с наступившей весной!

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

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



Лекцию читает старший научный сотрудник Вычислительного центра им. А.А. Дородницына РАН, доцент кафедры математических основ управления МФТИ, кандидат физико-математических наук Михаил Вялый.

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

Команда проекта GeeksLab 18 января 2014 года в Одессе провела конференцию Happу New Front-End: О фронтенде по-новому!. В рамках конференции были подняты темы современной верстки, разработки фронтенда на чистом JavaScript, а также использования различных CSS и JavaScrpt фреймворков для построения фронтенда веб-проектов. С докладами выступили представители таких компаний как: rollApp, Universal Mind, DataArt, Ciklum, Elis, R2Crew, RootUA Media, WMSoftware, Electric Cloud. Презентации и видеозаписи докладов под катом.

Продолжаем модернизировать приложение, которое мы создали в прошлой статье.

Сегодня мы разберем как создавать плитки (Tile) для Windows 8.1 приложений и каким образом можно реализовать динамическое изменение контента на них.

Весной 2012 г., Питер Тиль (Peter Thiel), один из основателей PayPal и первый инвестор FaceBook, провел курс в Стенфорде — «Стартап». Перед началом Тиль заявил: «Если я сделаю свою работу правильно, это будет последний предмет, который вам придется изучать».

Один из студентов лекции записывал и выложил транскипт. В данном хабратопике astropilot переводит пятнадцатое занятие.

Занятие 1: Вызов будущего
Занятие 2: Снова как в 1999?
Занятие 3: Системы ценностей
Занятие 4: Преимущество последнего хода
Занятие 5: Механика мафии
Занятие 6: Закон Тиля
Занятие 7: Следуйте за деньгами
Занятие 8: Презентация идеи (питч)
Занятие 9: Все готово, а придут ли они?
Занятие 10: После Web 2.0
Занятие 11: Секреты
Занятие 12: Война и мир
Занятие 13: Вы — не лотерейный билет
Занятие 14: Экология как мировоззрение
Занятие 15: Назад в будущее
Занятие 16: Разбираясь в себе
Занятие 17: Глубокие мысли
Занятие 18: Основатель — жертва или бог
Занятие 19: Стагнация или сингулярность?

Вступление

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

Когда я начинал писать на node.js, я ненавидел две вещи: все популярные шаблонизаторы и огромное количество callbacks. Я добровольно использовал callbacks, потому что понимал всю силу событийно-ориентированных серверов, но с тех пор в JavaScript появились генераторы, и я с нетерпением жду день, когда они будут имплементированы.

И вот этот день наступает. На сегодня генераторы доступны в V8 и SpiderMonkey, имплементация следует за обновлениями спецификации — это заря новой эры!

Некий dypsilon выложил на GitHub огромную коллекцию ссылок на ресурсы по веб-разработке, за что ему огромное спасибо.

Список состоит из ссылок на библиотеки, руководства и статьи.

Frontend: github.com/dypsilon/frontend-dev-bookmarks
Backend: gist.github.com/dypsilon/5819528 (много node.js)

Ссылок много, но все — строго по делу и упорядочены по группам (пример для фронтенда):

1. Архитектура
2. Фреймворки
3. Cross Browser
4. Cross Device
5. Паттерны и сниппеты
6. Манипуляция с DOM
7. … и многое другое

matmuchrapna советует еще frontdesk Вячеслава Олиянчука.
Настоятельно рекомендуется добавить в закладки, а лучше — почитать.