Добрый день, уважаемые посетители Хабра.



Несколько дней назад я прочитал замечательную книгу Гэвина Кеннеди «Договориться можно обо всём». Как верно отмечает автор, мы ведем переговоры с первых лет своей жизни, начиная еще до того, как научимся толком разговаривать, и важность правильно вести переговорный процесс, что в личной жизни, что в работе, очень сложно переоценить. Особенно важно умение вести переговорный процесс в IT индустрии, где заказчики и исполнители зачастую говорят на разных языках, и совершенно по-разному оценивают различные события и факты. Книга произвела на меня отличное впечатление, и я искренне рекомендую всем, при наличии свободного времени, ее прочитать. В процессе ознакомления с материалом, Гэвин предлагает читателям несложные тесты, и, далее, дает развернутые комментарии тех или иных наших ответов, классифицируя читателей по 4 категориям: Ослы, Овцы, Лисы и Совы, согласно умению вести переговорный процесс. Именно эти тесты, а точнее их автоматизация, и побудили меня написать этот пост на Хабре. Хотите проверить свой талант переговорщика?

Введение

В настоящий момент сложно себе представить программное обеспечение, работающее в одном потоке. Конечно, существует ряд простых задач, для которых один поток более, чем достаточен. Однако так бывает далеко не всегда и большинство задач средней или высокой сложности так или иначе используют многопоточность. В этой статье я буду говорить об использовании синглтонов в многопоточной среде. Несмотря на кажущуюся простоту эта тема содержит множество нюансов и интересных вопросов, поэтому считаю, что она заслуживает отдельной статьи. Здесь не будет затрагиваться обсуждение того, зачем использовать синглтоны, а также как их правильно использовать. Для прояснения этих вопросов я рекомендую обратиться к моим предыдущим статьям, посвященным разным вопросам, связанным с синглтонами [1], [2], [3]. В этой статье речь будет идти о влиянии многопоточности на реализацию синглтонов и обсуждению вопросов, которые всплывают при разработке.

(Окончание перевода статьи Эдди Османи о сравнении и выборе библиотеки для проекта со значительной ролью JS на клиенте.)
Содержание первой части:

■ Что такое MVC или, лучше сказать, MV*?
■ Когда нам нужен MV*-фреймворк JS?
■ Где же мы будем нуждаться в MV*, а где нет?
■ Проблема выбора: слишком много вариантов?
■ TodoMVC: общее приложение для обучения и сравнения
■ Предложенные нами критерии выбора фреймворка
■ Dojo и усложнение фреймворков на JavaScript
■ Коллекция TodoMVC (фреймворки, на которых сделаны реализации тестового приложения Todo)

В этой статье я хотел бы рассказать о том, как создать полноценное приложение на Python для Android. Нет, это не очередной мануал для создания скрипта для sl4a, это мануал по созданию полноценного приложения с UI, возможностью собрать apk и выложить на Android Market. Заодно я хотел бы похвалиться своим первым приложением на google.play, это не hello world, а полезное приложение для фотографов, хотя и узко специализированное.

Существует стереотип, что «IT»-шник должен сидеть в полумраке, освещаемый лишь светом монитора. Не знаю как вам, а мне всегда было комфортнее при ярком освещении. Сначала это было 3x100W обычных лампочек, потом 250W люминесцентных ламп, после последнего переезда — одна 500W галогенка… Но этого все-же было недостаточно. Всегда хотелось иметь такое освещение, чтобы не хотелось свет сделать ярче. О создании такой люстры я сейчас и расскажу.

На Хабре уже упоминалась новая рубрика What if Рендела Манро (xkcd). Каждый вторник он отвечает на разные дурацкие вопросы читателей с точки зрения законов физики. Ниже перевод одного из выпусков.

Что, если внезапно стакан станет буквально наполовину пустым?
—Витторио Иаковелла

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

Считается, что оптимисту стакан кажется наполовину полным, тогда как пессимист находит его наполовину пустым. Эта притча породила целую кучу шутливых вариаций (инженер видит стакан, который спроектирован с двукратным запасом емкости; сюрреалист видит жирафа, жующего галстук и т.п.)

Существует определенный набор возможностей в любом языке программирования для понимания которых нужно просто знать, как они реализованы. Вот, например, замыкания; это не сверх сложная концепция, но знание того, как этот зверь устроен позволяет делать определенные выводы относительно поведения замыканий с переменными цикла. Тоже самое касается вызова виртуальных методов в конструкторе базового класса: здесь нет одного правильного решения и нужно просто знать, что именно решили разработчики языка и будет ли вызываться метод наследника (как в Java или C#), или же «полиморфное» поведение в конструкторе не работает и будет вызываться метод базового класса (как в С++).

Еще одним типом проблемы у которой нет идеального решения, является совмещение перегрузки методов (overloading) и переопределения (overriding) метода. Давайте рассмотрим следующий пример на языке C#. Предположим, у нас есть пара классов, Base и Derived, с виртуальным методом Foo(int) и невиртуальным методом Foo(object) в классе Derived:

Intro

Привет, хабр! Ты наверное знаешь о недавних событиях, которые распиарили по интернету как «взлом» системы in-app покупок apple. Так вот, это было не совсем так. Это даже не было взломом. И ключевые выводы, которые я сделал:

• Закрытость<>Защищенность
• В Apple тоже очень даже ленивые люди работают

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

Технология

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

Очень интересная статья появилась сегодня на wired.com. Буквально за один час у автора статьи Мэта Хонана были взломаны Amazon, GMail, Apple и Twitter аккаунты и была удаленно уничтожена информация на его iPad, iPhone и MacBook. Среди прочего он потерял все фотографии своей дочки с ее рождения, многие документы и большую часть переписки. Очень интересно в этой истории то, как злоумышленник получил доступ к Amazon аккаунту и AppleID — для этого не понадобилась ничего, кроме доступной в сети информации и телефона.

Это перевод и форма повествования от первого лица сохранена. Автор — Бен Бойтер, бакалавр информационных технологий в Университете Чарльза Стерта (CSU).


Большинство людей не в курсе, но моей диссертацией была программа для чтения текста с изображения. Я думал, что, если смогу получить высокий уровень распознавания, то это можно будет использовать для улучшения результатов поиска. Мой отличный советник доктор Гао Джунбин предложил мне написать диссертацию на эту тему. Наконец-то я нашел время написать эту статью и здесь я постараюсь рассказать о всем том, что узнал. Если бы только было что-то подобное, когда я только начинал…

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

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

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

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

Приветствую.

Уж не знаю, как так вышло, но игрался я на досуге с лямбда-выражениями в С++11 (о которых, к слову, я уже писал статью, снискавшую пару лет назад на удивление достаточно неплохую популярность), и под наркотическим воздействием впечатлением от языка Haskell начал разбираться с такими понятиями, как частичное применение и каррирование в контексте языка С++. И для начала, пожалуй, неплохо бы нам определиться с этими терминами.

Внимание! Данная статья рассчитана на людей, имеющих представление о том, что такое инспекции кода, и желающих внедрить эту методику в своей компании.


Когда мы начинали заниматься процессом внедрения инспекций кода (code review) в своих проектах, то были неприятно удивлены отсутствием толковых материалов по организации этого процесса с нуля. Еще один крайне скудно освещенный аспект — это масштабирование процесса инспекций.

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

Итак, начнем.

0x00 Предисловие

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

English: PDF JPG SVG
Русский: PDF PNG SVG

Автор: Эндже Альбертини (Ange Albertini)
Перевод на русский: Lyr1k

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

Доделал на днях питонью библиотеку datrie, реализующую префиксное дерево (см. википедию или хабр), спешу поделиться.

Если вкратце, то можно считать, что datrie.Trie — это замена стандартному питоньему dict, которая при определенных условиях (ключи — строки) занимает меньше памяти, имеет сравнимую скорость получения отдельного элемента и поддерживает дополнительные операции (получение всех префиксов данной строки, получение всех строк, начинающихся с данной строки и др.), которые работают примерно так же быстро, как и «словарные» операции.

Работает под Python 2.6-3.3, поддерживает юникод, лицензия LGPL.

У меня достаточно много опыта в программировании, накопленного за последние несколько лет. Часть опыта я приобрёл работая в своей команде, что-то при работе с клиентам, а некоторый опыт появился благодаря coding dojo и работе на open source проектах.
Для программистов знающих как использовать парное программирование оно предоставляет возможность улучшить свою производительность. Но при этом не стоит ожидать, что программисты значительно улучшат свою производительность с самого начала работы. Парное программирование требует постоянного обучения, а также осознания самими программистами чёткой разницы между исполнителем (тот кто стучит по клавиатуре), и штурманом. Ниже приведено более детальное описание.

Очень многие жители северо-запада часто ездят в Финляндию за покупками и на отдых. В таких поездках очень не помешал бы нормальный интернет для звонков по СИПу/Skype'у (друзья просят привезти им чего-нибудь вкусненького из магазинов, а по скайпу им можно показать витрину), да и гуглокарты с он-лайн переводчиком очень полезны.

В своей первой же поездке в Лаппенранту я озаботился мобильным интернетом. В Финляндии развита контрактная система, поэтому для приезжих остается только «Prepaid» (т.е. предоплатная система расчётов, которая как раз сильно развита у нас). Вариантов с препейдом в Финляндии три:

1. DNA Dataprepaid, от оператора DNA. Даёт определенное количество трафика на 180 дней на скорости 21 мбит/с
2. SaunalahtiPREPAID, от оператора Elisa. Безлимитка на скорости до 4 мбит/с с оплатой по дням или пакетами на несколько дней.
3. Sonera Easy Prepaid безлимитка за 1.9€/сутки. Со скоростью не очень ясно.

Т.к. я езжу в Финляндию периодически и особые скорости мне не нужны, то меня заинтересовала Saunalahti.

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

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

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