Представляю вашему вниманию подборку интересных домашних офисов

Данная статья является кратким конспектом по книге "Andre Kukla: Mental Traps"

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

С «граблями» или ментальными ловушками можно легко справиться, если они лежат перед вами во всей красе, безо всякой маскировки. Но так бывает далеко не всегда и зачастую мы не видим и не понимаем в чем заключаются наши ошибки. Целью этой статьи является знакомство с наиболее «популярными» ментальными ловушками, которые Андре Кукла описал в своей книге.

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

Для затравки начнем с простого.

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

Про управление проектами написана тысяча книг. Разработано огромное количество методологий и проведены миллиарды тренингов.

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

Некоторые методологии просто предлагают принять это за данность и как-то приноровиться (например, планировать только ближайший этап), другие пытаются навести армейскую строгость, проводя Deadline и вводя «реакцию на отклонения».

Я хочу поговорить о другом. Не о том, почему проекты опаздывают, и как этого избежать, а о том, зачем они опаздывают. Ведь если так подумать – ну неужели можно все сбросить на ошибки планирования? Ведь, вроде взрослые, опытные люди, ну не могут же они все время ошибаться? А раз не могут – значит делают это намеренно, не так ли?

Приведу на ваш суд три возможных ситуации.

Ситуация первая. Швейцарский нож или «а еще кружок по фото, а еще нам петь охота»

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

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

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

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

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

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

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

TryGit — интерактивный обучающий курс по Github в стиле Codecademy. Курс состоит из 25 мини-уроков, которые знакомят пользователя с базовыми понятиями и основными командами git, при этом ученик своими руками вводит команды в консоль, смотрит результат и читает сопровождающие надписи с объяснением происходящего.



Вот таким в будущем должно стать обучение в школах!

Конечно, 15-минутное введение не заменит полноценного учебника. Для обучения можно рекомендовать бесплатную книгу Pro Git и видеокурс Getting Git.

От переводчика: The Codeless Code — сборник побасенок о философии программирования. Побасенки в сборнике разные — некоторые весьма кровожадные, некоторые достаточно хардкорные с технической точки зрения (родной язык автора — Java), но встречаются очень емкие. Представляю вам перевод семи наиболее полюбившихся мне историй, остальные 30+ (новые добавляются каждую неделю) можно найти на сайте.

Пустяк

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

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

Мастер ответил: «Здесь есть изъян, и я размышляю, как лучше его исправить.»

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

Прелюдия

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

Игра называется «найди десять отличий». Наше воображение мы назовем «Сферический конь в вакууме», а суровую действительность обозначим вопросом «Почему оно не работает?». А оно, как вы уже, наверное, догадались, не работает в 90% случаев. А это значит ровно то, что 90% времени, потраченного нами на образование и самообразование, потрачено впустую.

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

Будьте осторожны в своих желаниях — они сбываются!



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

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

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

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


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

• Бизнес архитектура
• Архитектура информационных систем (потоки данных)
• Технологическая архитектура

Таким образом, разработчики чаще всего говорят о технологической архитектуре приложения.

Бизнес архитектура, она же Enterprise, является представлением того, как эффективно воспроизвести цели бизнеса и стратегию путем создания, улучшения и объединения ключевых требований, принципов и моделей для успешного развития бизнеса и достижения поставленных целей. Определение взято из английской википедии.  Архитекторы уровня Enterprise должны ориентироваться на бизнес потребности и проводить анализ потоков данных, т.е. покрывают два указанных пункта. Архитекторы уровня Solution занимаются технологическими аспектами проектов. Так же стоит упомянуть не обозначенных здесь Infrastructure Architect, людей, которые занимаются глобальным развитием и анализом технических возможностей по реализации проектов.

Данный пост является переводом не статьи, как принято, а доклада+презентации, поэтому текст поста достаточно вольный.

Думаю, всем хорошо известно и очевидно, что PHP — один из самых популярных языков программирования, на котором написано множество веб-проектов, начиная с персональных homepage-страниц и заканчивая мастодонтами типа Facebook, Vimeo, WordPress и даже YouPorn.

PHP появился в 1995 году, при этом полноценная поддержка ООП была реализована только в PHP5, который вышел в 2005 году. За это время было написано большое количество кода, как хорошего, так и плохого, а точнее сказать сильно устаревшего и тяжело сопровождаемого.

Многие проекты, как и экосистема PHP в целом, к настоящему моменту стали представлять подобие оживленного городского квартала.

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

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

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

Для тех кто не в курсе, Knockout.js — это популярная JavaScript библиотека, позволяющая реализовать Model-View-View Model (MVVM) паттерн на клиенте. На Хабре уже много писали про него (раз, два, три, четыре, пять, видео). Освоить Knockout.js можно очень быстро — ведь есть система интерактивного обучения, куча живых примеров (можно потыкать и посмотреть исходный код) и прекрасная документация.

Очень часто Knockout.js используют в связке с ASP.NET MVC — ведь библиотека существенно упрощает написание клиентской логики. Однако, возникает много типичных проблем для клиент-серверной разработки: основную модель и часть логики её обработки приходится описывать как на клиенте (JavaScript), так и на сервере (C#/VB). Кроме того, есть рутинная часть, связанная с обращением клиента к серверным методам и передачи им модели для обработки. Но не стоит печалиться! Теперь у нас есть Knockout MVC — это .NET оболочка для Knockout.js, которая генерирует весь нужный JavaScript-код за нас. Нам остаётся только описать нашу модель на C# и в MVVM-стиле указать для каждого нужного html-элемента к какому свойству модели нужно привязаться (а можно указать и целые выражения — они будут транслированы в js). Таким образом, можно получить полноценное кроссбраузерное клиентское веб-приложение без единой строчки JavaScript!

Недавно (буквально два года назад) тут пробегала статья Только 10% программистов способны написать двоичный поиск. Двоичный поиск — это классический алгоритм поиска. Мало того, это еще чрезвычайно простой алгоритм, который можно очень легко описать: берем отсортированный массив, смотрим в середину, если не нашли там число, в зависимости от того, что в середине — ищем это число этим же методом либо в левой части, либо в правой, откидывая средний элемент. Для функций также, просто берем не массив, а функцию. Все очень и очень просто, алгоритм описан почти везде, все баги словлены и описаны.

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