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

Машина на 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.

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