Ты мне не веришь?

Что Microsoft делает хорошо?

...прощаясь с Балмером

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

Преимущественно, подобные нападки оправданы. Microsoft остается сильно ориентированной на Windows, рискуая проморгать бум мобильных устройств, консьюмеризацию ИТ и облачные сервисы.

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

Microsoft Office остается королем продуктивности

Возможно, Windows переживает трудности, но Microsoft Office все еще держит первенство в сфере ПО для повышения продуктивности. Да и настоящих соперников не наблюдается. Не смотря на то, что приложения Google Apps пытаются заявить о себе на рынке корпоративных решений, общая доля Microsoft Office составляет 95%.

Как понять, что вы - ИТ-директор

Будущее интернета

Я использую HTML примерно с 1993 года. Я долгое время занимался server-side разработкой, но даже тогда генерировал HTML. Однако, хотя бы раз в месяц мне напоминают о конкретном теге или атрибуте, о которых я забыл. Не заставляйте меня рассказывать о CSS. Каждый раз, когда я вспоминаю, что псевдокласс hover можно определить в CSS, мне вспоминается, сколько раз я писал тот самый чертов код, чтобы выделить пункты меню с помощью JavaScript. Я поставил себе целью сосредоточить свои усилия в этом направлении.

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

Веб-компоненты обозначают несколько разных технологий. Однако, в целом они отображают невероятные изменения в сети интернет. Я считаю их настоящим "Web 2.0." подходом, который предлагает много интересного. У вас впервые получится определить новые структурные элементы (метки, поведение, дизайн), следуя веб-стандартам. Вы сможете расширить сеть интернет и это круто.

Шаблоны

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

Хотя вы, разумеется, можете просто создать крупные блоки HTML в строках JavaScript, они достаточно быстро становятся громоздкими. Таким образом, появились различные фреймворки шаблонов JavaScript.

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

В отличии, к примеру, от Handlebars.js, здесь не происходит замена токенов. Зато требуется меньше дополнительного кода.

Больше о спецификации вы можете прочитать здесь: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html.

SDN -- это DNS для коммутации пакетов

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

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

Затем была SDN (программно-определяемая сеть), которая, в общем, представляет собой абстракцию DNS (система доменных имен), разработанную для сети.

По сути, вопрос сводится к "Мне нужно отправить информацию на этот IP-адрес. Куда я должен ее отправить?" Что, если задуматься, не так уж отличается от DNS, где проблема звучит как "Мне нужно отправить информацию на этот хост. Куда я должен ее отправить?"

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

Да, я излишне упростил суть SDN (а может, и нет), но если не вдаваться в детали, она выполняет ту же функцию для сети. SDN -- DNS для коммутации пакетов.

Знаю, что у некоторых теперь голова разрывается, ведь по сути все намного сложнее. Но если вы хотите объяснить, что такое SDN, людям, не увлекающимся сетями (или не разбирающимся в сетях третьего уровня, не говоря уже о втором), такой метод отлично подойдет. Когда вы пытаетесь доказать бизнесменам, почему в SDN стоит вкладывать деньги и время, вам придется постараться, чтобы ценностное предложение (отказоустойчивость, гибкость) было очевидным. В конце концов, DNS играет решающую роль в работе интернета, не так ли?

Отказоустойчивость DNS? Это есть и в SDN. Распределенность? Без проблем -- SDN. Модель централизованного управления DNS? Опять SDN. Процесс кэширования и переноса в DNS? Да, вы не ошиблись, этим может похвастаться и SDN.

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

Можно не гадать, распространяются ли пробелы безопасности, характерные для DNS, и на SDN.

источник

Влияние нового разработчика

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

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

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

Ниже приведены наблюдения и рекомендации касательно адаптации новых программистов в команде:

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


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


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


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


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


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


•  Не забывайте об этапах групповой динамики: Формирование, Урегулирование, Шторм и Результативная деятельность. Команды будут проходить данные стадии каждый раз, когда происходят изменения в штате. Способствуйте сплоченности команды, активно вовлекая новых участников во все -- не только рабочие -- виды деятельности.


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


•  Постоянно требуйте отзывов команды об успехах нового разработчика. Иногда новые участники приносят с собой лишний 'багаж" из другой команды/компании.

источник

Представьте мир...

Как повысить шансы своего резюме?

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

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

Прочитайте информацию о вакансии и возьмите ее за основу/шаблон

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

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

Звуки тишины

Ошибки 55 млн. лет назад

Первая война форматов

Что лучше?

Древнеегипетские регулярные выражения

Машина на 800 лошадок

10 ультрасовременных инструментов мобильной разработки

Разрабатывать мобильные приложения стало проще

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

Не нужно учиться премудростям Objective-C (iPhone) или Java (Android, BlackBerry), потому что с фреймворками разобраться легче.

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

AppGyver

AppGyver создает инструменты для разработки мобильных приложений, включая расширение PhoneGap под названием Steroids. Сервис Prototyper, наверняка, вас поразит, поскольку он позволяет соединить несколько страниц в прототип для проверки вашей концепции приложения. Конечный результат развертывается на вашем устройстве через QR-код или вы можете протестировать свой прототип прямо на веб-сайте AppGyver.

Гик Perl в зоопарке

Слишком много объектов

В 90-х гг. "объектно-ориентированное программирование" (ООП) было модным термином. Мне было интересно, что данный термин означал, но поиски приемлемого определения не были легкими. Я все еще помню описание, на которое наткнулся в каком-то источнике:

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

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

Когда вы не знаете, что это Yahoo

Oracle и ARM займутся оптимизацией Java

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

Работа предусматривает кастомизацию Java Platform Standard Edition для 32-разрядных процессоров ARM, что сделает Java более подходящей для встраиваемых систем, а также для 64-разрядных платформ ARMv8, где его можно использовать для создания корпоративного ПО.

Хотя изначально Java была разработана как кроссплатформенная технология, новый проект сосредоточен на улучшении производительности и масштабируемости Java-приложений на мультиядерных процессорах ARM.

На рынке встраиваемых систем Java - в паре с энергоэффективными ARM-чипами - мог бы найти применение в так называемом "Интернете вещей": при разработки систем управления и автоматизации производства.

ARM позиционирует свои процессоры как энергоэффективную альтернативу чипам x86. Усовершенствование одного из основных языков программирования и сред выполнения поможет привлечь больше клиентов.

По словам представителей ARM, оптимизированная виртуальная машина Java способна во многих отношениях увеличить производительность корпоративных Java-систем на мультиядерных процессорах ARM6: сократить время начального запуска и сэкономить энергоресурсы.

Компания приложила много усилий на стандартизацию Java на рынке встраиваемых решений. Инженеры ARM входят в состав подкомитета консорциума Java EEMBC (Embedded Microprocessor Benchmark Consortium), разрабатывающего критерии оценки встраиваемых систем и процессоров, и комитета Java Community Process Executive Committee.

источник

CAPTCHA

Почему бы не заработать пару лишних баксов

Чем больше SOA, тем лучше

Недавно в BestBuy

Как украсть пароли, которые хранятся в Google Chrome?

Получить доступ ко всем паролям, хранящимся в Google Chrome, удивительно просто. Еще один сюрприз: Google в курсе и компания не собирается ничего предпринимать.

Многие обеспокоены по поводу угроз безопасности в мобильной ОС Android. А вот о браузере Chrome и его безопасности почти ничего не слышно. Все может измениться - просто введите в Google "Как защитить пароли, сохраненные в Google Chrome".

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

Минигик

Искусство программирования

Тяжелая работа

14 способов перейти на следующий карьерный уровень в ИТ

Это был удачный год для области технологий - эксперты сообщили, что 10% всех новых рабочих мест в июне были созданы именно на этом рынке. Ожидается, что подобная тенденция сохранится до конца 2013 года.

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

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

Поговорите со своим руководителем и менеджером по подбору персонала

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

Хорошее управление требованиями

Facebook создаст виртуальную машину для PHP

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

"Наша цель - сделать PHP действительно быстрым", - заявил менеджер по разработке Facebook Джоэль Побар.

С начала года Facebook использовала виртуальную машину HHVM (HipHop Virtual Machine) на своих серверах.

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

Очень толстая книга "Фейсбук"

Почему для технаря талант и навыки - вещи разные?

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

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

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

Реальные друзья

Jenkins (и другие) откажутся от поддержки Java 5

Создатель сервера непрерывной интеграции Jenkins CI Косуке Кавагучи работает над интересной инициативой. Он призывает открытые проекты и разработчиков отказаться от поддержки Java 5. Хотя такое изменение окажется несущественным для большинства открытых проектов, оно окажет ощутимое влияние на серверы непрерывной интеграции вроде Jenkins.

Что?

Мы обязаны заявить: наши релизы после 30-го сентября 2013 года в качестве минимальной среды исполнения будут требовать Java 6. Мы хотим предупредить об этом наших пользователей. Чтобы достичь поставленных целей, мы объединяемся с открытыми проектами. Вся информация будет размещена на веб-сайте. Мы призываем людей распространять новости, а помогут им в этом названия и логотипы наших коллективных проектов.

Мы -- разработчики открытого проекта. Чтобы позволить пользователям применять наше ПО, до настоящего времени мы не требовали Java 6 в качестве минимальной среды исполнения. Однако, пришло время двигаться дальше.

Почему?

Доводов, на самом деле, очень много:

• Многие поставщики виртуальной машины Java больше не поддерживают Java 5.
• Отсутствие жизнеспособной открытой реализации Java 5.
• Невозможность использовать библиотеки, требующие Java новых версий. Как результат, количество новых функций и исправлений уменьшается, а усилий на разработку уходит больше.
• Повышаются затраты на интеграционное тестирование. Мы проводим больше тестов для Java 5, в то время, как все меньше разработчиков работают с ней.
• Среды выполнения Java новых версий обладают богатым набором возможностей. Больше API коллекций, усовершенствования NIO, консольный доступ, поддержка XML, Java Compiler API, процессоры аннотаций и интерфейс скриптового языка.
• Формат класс-файла версии 1.50 распространяется совместно с верификатором Split-Verifier, что позволяет ускорить загрузку классов.
• Объединив усилия, мы сможем добиться увеличения количества пользователей.

Факты

• Java 5 вышла в 2005 году, почти десять лет назад. в 2009 достигла стадии полного прекращения поддержки.
• Даже IBM откажется от поддержки Java 5 на стороне сервера 30-го сентября 2013 года. 

источник

Пунктуация

Документация продукта: степень ее пригодности решает получатель

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

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

Большинство продуктов на рынке обладают некой документацией - первый шаг в правильном направлении - однако, пользователи продукта сталкиваются со следующими трудностями:

Документация слишком сложная.

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

Документацию невозможно найти.

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

Еще одно препятствие, с которым сталкиваются пользователи: найдя предметный указатель документации, на них обрушивается такой поток информации, что они не знают, к какому пункту переходить. Решение есть: сосредоточить документацию на простой теме и предоставить ссылки для тех, кто желает изучить ее детально.

источник

Канбан - тайный убийца инженеров

Вы когда-нибудь сидели на диете? Хотя две трети американцев заявляют, что сидят на диете, чтобы поправить здоровье, лишь несколько в действительности худеют. Более 90% диет не эффективны. 75% приводит к набору веса. Если бы любая деятельность демонстрировала такое количество неудач, мы бы немедленно ее прекратили.

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

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

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

• давление общественности;
• мы больше сосредоточены на своей внешности, чем на здоровье в перспективе;
• мы не контролируем себя.

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

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

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

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

Мы привыкли

Настоящие кодеры помогают друг дугу

После длинного дня работы над проектом

Что на работе мешает создать лучший код: кодировщики-ковбои и плохая документация

Вы только что получили Null Pointer Exception? Ловить его - ваша обязанность. И подумайте дважды, прежде чем передавать нулевое значение, поскольку поглощенный собой кодировщик не проверяет наличие ошибок деления на ноль. Это ваша работа.

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

Многие команды начинают слишком поздно это понимать. Во время начальных тестов блоки кода работают нормально, но когда через них "проталкивают" реальные данные, становится понятно, что никто не проверял их на наличие ошибок. Упс.

Плохая документация

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

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

 источник

Резюме для руководства

Что на работе мешает создать лучший код: менеджеры-программисты и брограммисты

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

Или будут рассказывать, как им удавалось добиться аналогичных результатов с помощью половины кода, программируя на ассемблере 8080, C или Java. В любом случае, они могут зациклиться на технических деталях, а не на общей картине. Несмотря на то, что их наняли следить именно за общим результатом. 
   

"Брограммисты"

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

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

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

Как результат, ничего не доводят до конца.

 источник

Как создавать корпоративное ПО

Приближается время iPhone

"Примирение" программной архитектуры и кода

Многие команды разработчиков ПО структурируют код уровень за уровнем. Другими словами, если открыть код, вы увидите пакет для классов предметной области, один для пользовательского интерфейса, один для "бизнес-сервисов", для доступа к данным, другой - для точек интеграции и т.д.

Этому есть простое объяснение. Нам известно, что делить на уровни - хорошо и многие учебники приводят такой подход в качестве способа структурирования кода. Если погуглить, например, учебные пособия по Spring или ASP.NET MVC, то это показано в их примерах. Я провел в Лондоне более 10 лет, создавая программные системы на Java, и тоже часто использовал пакетирование для проектов, над которыми работал.   

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

Если вы используете объектно-ориентированный язык программирования, вы говорите об "объектах" во время архитектурных дискуссий? Из собственного опыта отвечу - нет. Я слышу, что преимущественно люди используют понятия "компоненты" и "сервисы". В результате, "компонент" на диаграмме архитектуры реализуется с помощью комбинации классов на нескольких разных уровнях.

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

Итак, к чему это?

Вопрос о дате

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

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

Новогоднее обязательство кодера

17 советов разработчикам для защиты кода

Совет №1: Строго тестируйте входные данные

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

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

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

Что на работе мешает создать лучший код: рабская приверженность к документации

Мы все имели дело с проектами без документации. С другой стороны, проекту не идет на пользу чрезмерная многословность. Однажды мне показали полку, наполненную талмудами и сказали "Им платили за документацию". Что бы все прочитать понадобится год.

Программисты часто подходят к требованию написать комментарий так же, как к обсуждению телесериала "Звездный крейсер ‘Галактика’" или "Доктор Кто": пишут кучу страниц, выкладывают мельчайшие подробности, но так и не доходят до сути.

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

 источник

Наконец Google Maps добрались до iPad

По иронии судьбы, iOS получила обновление приложения позже, чем Android. Последняя версия приложения "Карты Google" для iOS обладает почти тем же набором функций, что и прошлонедельное обновление для Android. Теперь версия для iOS, которую можно скачать в магазине App Store, получила поддержку всех мобильных телефонов и планшетов на iOS 6: iPhone, iPod Touch и iPad.

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

Чтобы вы могли видеть, что находится в окрестности, места, соответствующие параметрам поиска, отображаются красными иконками. Кроме того, новые информационные карточки (Info Sheets) в нижней части экрана можно смахивать для навигации по этим "красным точкам". Если один из результатов поиска вас заинтересовал, проведите пальцем снизу вверх, как будто вытягивая информационную карточку, чтобы получить детальную информацию о нужном пункте, включая фотографии и рецензии от Google+ и Zagat.

Социальные сети нас сближают