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

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

^{*слоган одной очень известной торговой онлайн-площадки: Smarter Shopping, Better Living!}

Нашалившего ребёнка родители теперь ставят в тот угол, где нет WiFi — из эфира одной популярной радиостанции

Помню, когда я пару лет назад покупал очередной смартфон, то слегка удивил консультанта своей методикой выбора устройства: сперва нашёл у известного производителя аккумуляторов варианты с самой большой ёмкостью, и уже по ним смотрел совместимый смартфон. Объясняю консультанту: «нет, спасибо, чехол мне не нужен, я меняю крышку заднего отсека… Потому что когда батарея сдохла, уже не важно, сколько там ядер и какая версия Android...»

DISCLAIMER: автор выражает благодарность советской спичечной промышленности за эталон 5см (плюс-минус 1мм по ГОСТ 1820-2001), но никак не аффилирован с торговой маркой «Балабановские Спички»; все появления означенной марки в кадрах непреднамеренны.
Чтобы поднять читателю настроение, автор придумал каждому изделию шуточное название и perk на манер популярной компьютерной игры Fallout, специально для Geektimes.

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

Итак, сколько плохих кабелей micro USB вы выбросили за последние пару лет? Лично я уже штук пять. А как понять качество кабеля, если заряд идёт, видимых повреждений нет, да и разъёмчик хорошо сидит? Как комфортнее электрифицировать гаджеты в автомобиле, в самолёте, в лесной глуши и на горной вершине?

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

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

Итак, 7 золотых правил при отвлечении коллег просьбами о помощи:

Введение

У одного из наших клиентов возникла задача вынести логи из большинства корпоративных приложений и их баз данных «куда-нибудь» — уж больно с ними много возни: растут как на дрожжах, чисти их периодически, а к некоторым еще и доступ должен быть обеспечен в течение многих лет, да еще и анализ хочется проводить системным образом. Конечно же, вынести логи – это не первичная цель, и по совокупности требований мы выбрали Hadoop, версию от Cloudera (CDH 5).

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

Как одно из решений — использовать поисковый модуль SolrCloud, который входит в комплект Hadoop от Cloudera. В Cloudera «из коробки» входят тулзы для выгрузки данных из баз данных приложений и их индексации пачкой (не построчно). Однако такой способ оказался хоть и рабочим, но более трудоемким и непредсказуемым в настройке, чем, скажем, если бы мы использовали Impala для выборки данных. Поэтому я решил поделиться как мы это делали, в надежде сэкономить время тем, кто столкнется с похожей задачей.

Эта статья описывает детали настройки, а также встреченные в процессе работы особенности.

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



Сегодня мы хотим рассказать, как с помощью технологий Microsoft можно превратить панорамные снимки с вашей Lumia (впрочем, и с любого другого устройства тоже) в ультраширокоугольные произведения искусства. Все, что для этого нужно – новая версия Image Composite Editor (ICE) от нашего подразделения Microsoft Research.

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

Для их реализации мы исследовали и опробовали некоторое количество инструментов, среди которых были Apache JMeter и написанный нами на Python скрипт LogSniper, который выполнял реплей заранее подготовленных серверных логов с HTTP-запросами на цель.

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

Вопрос: Почему поиск в python dict на больших объемах данных быстрее чем итерация по индексированному массиву?

Ответ: В dict хранятся хэши от ключей. Каждый раз, когда мы ищем в dict значение по ключу, мы сначала вычисляем его хэш, а потом (внезапно), выполняем бинарный поиск. Таким образом, сложность составляет O(lg(N))!

На самом деле никакого бинарного поиска тут нет. И сложность алгоритма не O(lg(N)), а Amort. O(1) — так как в основе dict питона лежит структура под названием Hash Table.

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

По следам недавнего топика «Обработка больших объемов данных в памяти на C#» представляю перевод упоминавшейся там статьи о структурах.

Структуры являются фундаментальными типами данных в C# и большинстве других современных языках программирования. По своей сути структуры просты, но вы можете удивиться, насколько быстро работа с ними может стать сложной. Чаще всего проблемы возникают, если вы должны работать со структурами, созданными в других языках и сохраненными на диске или полученными в результате вызова функций из библиотек или COM-объектов. В этой статье я подразумеваю, что вы знакомы с понятием структуры, умеете определять их и владеете базовыми навыками работы со структурами. Предполагается, что вы имеете представление о том, как вызывать API функции с использованием p/Invoke, а также что такое маршалинг. В случае неуверенности в своих знаниях вы можете обратиться к документации.
Множество техник, описанных в данной статье, могут быть расширены и применены к любым типам данных.

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

Исправляюсь! Теперь понятным языком и с юмором!

Чёрная пятница оказалась воистину чёрной для aмериканского интернет-универмага Kohl's. Все сервера накрылись медным тазом именно в день рождественских распродаж. Привычные 20% годового дохода, добываемые в этот день, обернулись смешным пустяком, а все потому что Боливар не вынес такой нагрузки.

Традиционная архитектура Tomcat + WebLogic + БД облажалась по полной программе! Напрасно бегали по этажам сисадмины, суетились в панике ведущие программисты, а архитекторы выдирали остатки волос… Горлышко бутылки оказалось слишком узким для того, чтобы в него могли протиснуться все потенциальные клиенты и недостаточно эластичным, чтобы за короткое время его можно было успеть расширить. Бутылку разорвало нахрен. И долго еще кровоточили раны, нанесённые ее осколками…

Обработка данных in-memory является довольно широко обсуждаемой темой в последнее время. Многие компании, которые в прошлом не стали бы рассматривать использование in-memory технологий из-за высокой стоимости, сейчас перестраивают архитектуру своих информационных систем, чтобы использовать преимущества быстрой транзакционной обработки данных, предлагаемых данными решениями. Это является следствием стремительного падения стоимости оперативной памяти (RAM), в результате чего становится возможным хранение всего набора операционных данных в памяти, увеличивая скорость их обработки более чем в 1000 раз. In-Memory Compute Grid и In-Memory Data Grid продукты предоставляют необходимые инструменты для построения таких решений.

Задача In-Memory Data Grid (IMDG) — обеспечить сверхвысокую доступность данных посредством хранения их в оперативной памяти в распределённом состоянии. Современные IMDG способны удовлетворить большинство требований к обработке больших массивов данных.

Упрощенно, IMDG — это распределённое хранилище объектов, схожее по интерфейсу с обычной многопоточной хэш-таблицей. Вы храните объекты по ключам. Но, в отличие от традиционных систем, в которых ключи и значения ограничены типами данных «массив байт» и «строка», в IMDG Вы можете использовать любой объект из Вашей бизнес-модели в качестве ключа или значения. Это значительно повышет гибкость, позволяя Вам хранить в Data Grid в точности тот объект, с которым работает Ваша бизнес-логика, без дополнительной сериализации/де-сериализации, которую требуют альтернативные технологии. Это также упрощает использование Вашего Data Grid-а, поскольку в большинстве случаев Вы можете работать с распределённым хранилищем данных как с обычной хэш-таблицей. Возможность работать с объектами из бизнес-модели напрямую — одно из основных отличий IMDG от In-Memory баз данных (IMDB). В последнем случае пользователи всё ещё вынуждены осуществлять объектно-реляционное отображение (Object-To-Relational Mapping), которое, как правило, приводит к значительному снижению производительности.

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

1) Кэширование результатов выполнения запросов

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

2) NoSQL решения

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

Сегодня я хочу познакомить вас с таким типом хранилища данных, который объединяет достоинства обоих подходов и при этом имеет ряд преимуществ перед упомянутыми выше решениями: In-memory-data-grid (IMDG).

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

В статье посвященной моему профайлеру для Entity Framework-a, я вкратце описал примененную мной форму для сообщения пользователю об исключительной ошибке в приложении. После оценки количества скачиваний примера кода, было решено выделить этот пример в отдельный проект, а также добавить поддержку WPF приложений.
Исходники библиотеки вместе с примерами опубликованы на CodePlex под свободной лицензией MIT: https://uiexceptionhandler.codeplex.com/

Подробности под катом.

Сегодня мне случилось побывать на лекции Эрика Райса (Eric Reiss), специалиста по вопросам информационной архитектуры, юзабилити и user experience.

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

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

Вот эти 10 правил.

Eric Ligman, Директор по партнерским программам компании Microsoft, опубликовал в блоге ссылки на большую бесплатную коллекцию книг Microsoft по самым разным направлениям: SharePoint, Visual Studio, Windows Phone, Windows 8, Office 365, Office 2010, SQL Server 2012, Azure, Cloud, Lync, Dynamics CRM и т.д.

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

Эта статья входит в серию статей по улучшению производительности в .NET. Первую статью можно найти здесь.

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

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

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

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

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

Одним из недешевых процессов с точки зрения производительности является boxing и unboxing. Напоминалку о том, что это такое, можно найти тут. Недавно я решил посмотреть весь IL код наших проектов и поискать инструкции box и unbox. Нашлось достаточно много участков, boxing'а в которых можно избежать легким движением руки. Все случаи, приводящие к ненужному boxing'у, очевидны, и допускаются по невнимательности в моменты концентрации на функциональности, а не на оптимизации. Я решил выписать наиболее часто встречающиеся случаи, чтобы не забывать о них, а затем автоматизировать их исправление. В данной статье и перечислены эти случаи.

Привет, Хабр! Мы продолжаем цикл публикаций о e-mail рассылках. На сей раз поговорим о том, каким способом их лучше организовывать — приобретая специализированный софт или используя онлайн-сервис.

Критериев оценки много, но главные — это затраты и безопасность. С них и начнём.

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

Что такое спам? Это 80% почтового трафика в интернете и 20% эффективности. Обычная, грамотно сделанная email рассылка, будет в разы эффективнее. Но даже с самыми благими намерениями всегда есть риск попасть в чистилище папки «Нежелательная почта». Чтобы этого избежать, нужно учитывать ряд нюансов.

Как обычно, саммари в начале статьи и дальше — подробные пояснения. Итак, 9 простых правил:

1. Не занимайтесь спамом
2. Спрашивайте у адресатов согласия на рассылку
3. Обновляйте ваши базы адресов
4. Не используйте покупные базы
5. Храните подтверждения о законности вашей базы
6. Давайте возможность отписаться прямо из рассылки
7. Не повторяйтесь
8. Красиво и грамотно составляйте письма
9. Учитывайте требования спам-фильтров

Привет, %username%!

Так уж вышло, что несмотря на относительно неплохое понимание инфраструктуры открытых ключей, содержимое *.crt файлов всегда оставалось для меня полнейшей загадкой.
Нет, не поймите неправильно. Я знаю, что x.509 сертификат содержит информацию о владельце, открытый ключ, сведения об удостоверяющем центре и электронную цифровую подпись. Но при установке очередного сертификата меня всегда мучило любопытство.
Чем отличается идентификатор ключа от отпечатка? Какие данные сертификата подписываются, а какие нет? И что за структура данных позволяет хранить всю эту информацию, сводя избыточность к минимуму.
Но вот наконец-то любопытство перебороло лень и в данном посте я постараюсь описать структуру x.509 сертификатов и ответить на эти и другие вопросы.