На Хабре уже написано достаточно много статьей по теме, в частности:

• 2 статьи о работе с Upwork (в прошлом известном как oDesk)
  • Легальный вывод денег из oDesk в РФ от 11 января 2013
  • Легальный вывод денег с oDesk на р/c ИП от 4 сентября 2012
• 4 статьи о работе с иностранными заказчиками
  • Практика работы «в белую» с иностранными заказчиками от 14 ноября 2011
  • Тонкости при работе с иностранным заказчиком от 10 ноября 2011
  • Почему ИТшнику стоит стать ИПшником и почему не стоит регистрировать ООО от 9 ноября 2011
  • ООО и ведение валютных операций от 18 февраля 2011
• 3 статьи о неочевидных налогах
  • НДС и фрилансеры, работающие с Upwork от 8 апреля 2017
  • Налоговый cуслик — 2. «Налог на Google» и агентский НДС от 15 января 2017
  • Налоговый суслик. Особенности УСН при работе по договорам с Apple, Google и другими от 16 июля 2015

В ответ на повторяющиеся просьбы написать статью, в которой:

• разбросанные по разным статьям крупицы будут собранны в единое целое
• всевозможные противоречия будут устранены
• все сведения будут иметь актуальный характер
• будут учтены пожелания такие как «а можно с картинками? :)»

родилось следующее руководство.

Друзья, спасибо за позитивные комментарии после нашего последнего видео «Как навести порядок снизу: за 90 дней от бардака к проектному офису»! Мы решили продолжить разговор с нашим экспертом по управлению проектами Иваном Селиховкиным (selikhovkin). И затронули такую холиварную тему, как знания и навыки, которыми должен обладать хороший ПМ.

Я отчетливо помню, как после пары лет работы в Intel у меня возникло четкое убеждение, что я знаю, как надо. Убеждение было вскоре многократно пересмотрено после работы с аутсорсинговыми компаниями (о, сколько там многообразия!), стартапами, ИТ-отделами не-ИТ компаний и т.д.

Расширение контекста (не важно, инженера или менеджера) – чертовски важная штуковина. Поэтому помимо набивания собственных шишек, мне всегда было интересно разговаривать с людьми, имеющими разносторонний опыт и широкий кругозор. selikhovkin – безусловно, один из них. Как человек системный, Иван набросал еще и интеллект-карту «Знания и навыки хорошего менеджера проекта», по которой и вел рассказ.

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

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

Мы пригласили в студию нашего эксперта по управлению проектами Ивана Селиховкина (selikhovkin) и попросили поделиться историей наведения порядка. В итоге Иван рассказал историю о том, как он с коллегами по шагам за 90 дней привел компанию от хаоса к работающему проектному офису. Находясь при этом не на должности ТОП-менеджера. Все изменения шли СНИЗУ.



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

Если это видео придаст правильный заряд, будем категорически рады. Хороших выходных!

P.S. Если поможете нам с опросом по проблемам проектов — будем отдельно благодарны.

P.P.S. Краткое содержание истории по шагам — под катом:

или «Прекратите характеризовать хранилища данных как CP или AP»

Джеф Ходжес в своем прекрасном посте «Заметки о распределенных системах для новичков» рекомендует использовать САР теорему для критики найденных решений. Многие, похоже, восприняли этот совет слишком близко к сердцу, описывая свои системы как «СР» (согласованность данных, но без постоянной доступности при сетевой распределенности), «АР» (доступность без согласованного состояния при сетевой распределенности), или иногда «СА» (означает «Я всё ещё не читал статью Коды (Coda Hale) почти 5-летней давности»).

Я согласен со всеми пунктами статьи кроме того, что касается САР теоремы. Она слишком всё упрощает и слишком многие понимают её неверно для того, чтобы использовать для определения характеристик системы. Так что я прошу перестать ссылаться на САР теорему, говорить о ней и дать ей уже спокойно уйти на покой. Вместо неё мы должны использовать более точную терминологию для обсуждения различных компромиссов.

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

САР использует слишком узкое определение

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

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

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

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

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

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

В Яндексе тестировщику невозможно без автоматизации. Мы даже развиваем экспериментального робота, который способен брать на себя функциональное тестирование. В какой-то момент мы поняли, что не так много людей осознают, сколько сейчас есть возможностей работать не 12 часов, а головой. Собрав весь свой опыт в тестировании и деплое, мы открыли в питерском офисе Яндекса Школу автоматизации процессов разработки. У нас получилась школа, где каждый, кто пишет код, может получить базовый набор знаний о том, как собрать, запустить и поддерживать сервис в продакшене так, чтобы это стоило недорого.



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

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

Привет! Меня зовут Антон Карпов, в Яндексе я руковожу службой информационной безопасности. Недавно передо мной встала задача рассказать школьникам — студентам Малого ШАДа Яндекса — о профессии специалиста по безопасности. Я решил, что вместо скучной теории, которую и так можно прочитать в учебниках (да и что расскажешь за одну лекцию!), лучше рассказать историю компьютерной безопасности. На основе лекции я подготовил этот короткий рассказ.



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

tmux — это менеджер терминалов, к которому удобно подключаться и отключаться, не теряя при этом процессы и историю. Как screen, только лучше (в первую очередь потому, что использует модель клиент—сервер).



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

Я обычно стараюсь писать по делу, но иногда можно и поразмышлять об абстрактном. Не так давно мне в руки попалась неплохая (и, пожалуй, единственная в своём роде) книга 1001 Video Games You Must Play Before You Die, авторы которой взяли на себя титанический труд вычленения лучшей, по их мнению, тысячи игр за всю историю индустрии. Учтены практически все известные платформы, начиная с аркадных машин семидесятых годов и заканчивая Xbox360 и iPhone. Конечно, любой хит-парад (даже если в нём аж 1001 позиция) субъективен, и каждый из нас может с удивлением не обнаружить в нём любимой игры. Ещё авторы явно благоволят последнему десятилетию, которому досталась половина всей книги. С другой стороны, к их чести заявленным форматом «1001» дело не ограничивается, и частенько проскакивают комментарии вроде «эта игра имела такого-то предшественника, а позже аналогичная идея была воплощена в таком-то проекте», по сути расширяющие основной список. Однако мне бросилась в глаза ещё одна особенность, которая, как мне кажется, отражает любые «списки лучших» чего бы то ни было, а именно явное преклонение перед великими работами.

Продолжаю серию постов, посвящённых апгрейду компьютеров Apple. На этот раз речь пойдет о MacBook Pro 15” (A1286) выпуска 2011г. Очень достойный аппарат, на мой взгляд: четырёхъядерный процессор Intel Core i7, графика Ati 6 серии, поддержка 16GB оперативной памяти 1333MHz. Его производительности и на сегодняшний день, вполне хватит для большинства задач.

Apple выпустила четыре комплектации этой модели, которые отличается процессором и графикой. Подробные характеристики смотрите в таблице. Эксперимент был проведен над комплектацией MD 318 (i7 2.2GHz, Ati 6750M(512MB)). Штатную видеопамять (vram) объёмом 512MB, перепаяли на более ёмкие чипы и получили 1GB vram.

На это неделе мы узнали как стать ниндзя Xcode, возмутились политикой Google Play, рассмотрели ему альтернативы, научились делать прототипы и встраивать планшет в автомобиль. Мобильная разработка не затихает даже в жарком августе!

Примечание от переводчика:

Я решил перевести эту статью в основном из-за личности автора. TJ вложил очень много усилий в развитие Node.js и его инфраструктуры, он автор таких проектов как express, jade, mocha, stylus, автор 550 репозиториев на npm. Существуют также теория, что под этим именем скрывается группа людей.

Как бы то ни было, JavaScript и Go сообщества в ближайшие время ожидают изменения.

Покидая страну Node.js

Я сражался с Node.js достаточно долго, что бы перестать получать от этого удовольствие, это мое официальное прощание! И, что еще важнее, я ищу людей, которые смогут поддерживать мои проекты!

Node отлично справляется с некоторыми вещами, но, к сожалению, это не самый подходящий инструмент для того, что мне сейчас интересно. Я все еще планирую использовать его для сайтов, но если вы хотели бы заняться поддержкой одного из моих проектов, дайте мне знать. Просто оставьте комментарий с вашим именем на Github, ссылкой на npm и названием проекта. Как обычно я прошу не делать больших изменений в существующих API: создать новый проект будет проще.

Я также продолжу поддерживать Koa.

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

Помните эти задачи «при помощи циркуля и линейки постройте...»? Вот здесь можно поупражняться в таких построениях.

20 уровней построены по принципу «от простого к сложному». Предыдущие достижения (к примеру, умение строить равносторонний треугольник) на следующих уровнях доступны уже в виде инструментов.

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

Пост содержит перевод статьи «Error Handling in Node.js», которую подготовили сотрудники компании Joyent. Статья была опубликована 28 марта 2014 года на сайте компании. Dave Pacheco поясняет, что статья призвана устранить неурядицу среди разработчиков, касаемо лучших практик работы с ошибками в Node.js, а так же ответить на вопросы, которые часто возникают у начинающих разработчиков.

Итак, подошел к концу наш хабра-конкурс «Истории, которые меня многому научили»:

• Лучшей историей по оценке хабровчан стала история itblogger про ускорение коммуникаций
• Приз наших симпатий получила история craft_brother про правильную командность

Глядя на конкурс историй, мой коллега SlavaPankratov вспомнил две истории из своего прошлого, которые его многому научили:



Из этого видео вы узнаете:

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

P.S. В свое время мы все свои ошибки и инструменты, к которым пришли, свели в подробную интеллект карту «Формула работы с людьми», про которую SlavaPankratov как раз упоминает в видео. Скачать ее можно ниже – под катом.

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

С подробностями Егор Тафланиди, Redmadrobot.

Вот так неожиданно, через 15 лет после начальной публикации, обновилась спецификация HTTP/1.1
Обновлений много, я бы даже сказал, дофига. Добавили много проясняющего текста, разбили спецификацию на 6 RFC (раньше было 2), добавили новый статус 308, стандартизировали X-Forwarded-For (теперь он просто Forward), и еще много всего.

Неполный спискок изменений:

• Новый статус 308 — Permanent Redirect, но с отправкой этих же самых данных. Т.е. запрос не меняется на GET, как раньше.
• Новый заголовок Forward, который призван заменить X-Forwarded-For и X-Forwarded-Proto
• Убрано ограничение на 2 подключения к серверу
• Убрана поддержка HTTP 0.9
• Убрана кодировка ISO-8859-1 по умолчанию
• Убран заголовок Content-MD5
• Запрет использования Content-Range на POST-запросах
• Добавлено кеширование кодов 204, 404, 405, 414 и 501
• Изменена документация кодов 301 и 302 таким образом, чтобы позволить перенаправлять метод с POST на GET. Т.е. задокументировали текущую реализацию всех браузеров.
• Добавлены разграничения между запретом отправки referer и случаем, когда referer нет. Теперь следует отправлять Referer: about:blank, если referer-а не было.
• Location теперь может перенаправлять на ссылку с хештегом.

На Хабре в свое время было несколько статей «Очень много полезных штук для AS3». Автор попытался собрать ссылки на самые полезные и интересные библиотеки. И т.к. в последнее время я разрабатываю под iOS, решил последовать его примеру и сделать то же самое, но для своей платформы. Описания почти прикладывать не буду, все есть на страничках проектов.

На Хабрахабре неоднократно писали о великолепном графическом редакторе Scratch (Скретч) для программирования в интуитивно понятной визуальной среде. Здесь можно перетаскивать объекты мышью, устанавливать взаимодействия между ними, словно в конструкторе Lego. Рабочие программы собираются из разноцветных кирпичиков-команд.

Несколько дней назад разработчики из Массачусетского технологического института выложили на Github исходный код Скретч 2.0 под свободной лицензией. Этот код используется как основа для онлайновой и офлайновой версий Скретча.