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

Чтобы разобраться в этом пришлось поставить несколько опытов на кошках, зато теперь кое-что прояснилось.

Агентство по национальной безопасности США опубликовало новую версию 200-страничного руководства (PDF) по безопасной конфигурации Red Hat Enterprise Linux 5. Это весьма подробный мануал, который объясняет принципы защищённой системы и на практике указывает все необходимые настройки и перечень сервисов, которые обязательно нужно отключить (это один из базовых принципов: минимизировать количество софта).

Есть и что-то вроде шпаргалки на листе A4, тоже очень удобно.

Хочу поделиться с вами примером того как можно использовать такую удобную штуку как Thrift в своих .NET проектах.

Для тех кто не знает, Thrift — это фреймворк для облегчения взаимодействия между кодом написанным на разных языках, а именно C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk и OCaml.

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

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

1. Сэкономите кучу времени для написания клиент серверного приложения, например с использованием сокетов.
2. Почти автоматически получаете клиентов на всех поддерживаемых языках.

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

В первой части мы познакомились с Protocol Buffers и попробовали использовать их в .Net приложении. Сегодня мы продолжим дискутировать и ответим на оставшиеся вопросы. Как и прежде читатель должен немного владеть языком C# и системой контроля версий SVN для лучшего усвоения материала. Также не помешает иметь общее представление о WCF, т.к. будет снова (не)много кода, но уже в контексте этой технологии!

От переводчика: Это перевод статьи от одного из разработчиков ASP.NET, в которой подробно рассказывается о механизме управления состоянием страницы — ViewState'е. Несмотря на то, что статья написана в 2006 году, она до сих пор не потеряла своей актуальности.

ViewState — очень непонятное существо. Я попытаюсь положить конец всяческим кривотолкам, и постараюсь объяснить, как на самом деле работает механизм ViewState'а, от начала до конца, посмотрев на него с различных точек зрения.

Есть множество статей, авторы которых пытаются развеять мифы о ViewState'е. Можно даже подумать, что это все — борьба с ветряными мельницами (где ViewState – ветряные мельницы, а Интернет – инструмент борьбы). Но, я вам доложу, мельницы ещё не остановились. Как раз наоборот, они вертятся и заполняют собой вашу гостиную. Пора бы нанести по ним ещё один удар. Не тревожьтесь, при написании этой статьи ни одна ветряная мельница не пострадала.

Предлагаю вашему вниманию введение в использование Protocol Buffers на платформе .Net в формате дискуссии. Я расскажу и покажу что это такое и зачем оно нужно .Net разработчику. Топик требует от читателя начального владения языком C# и системой контроля версий SVN. Так как объем материала превышает среднестатистический объем топиков на хабре, которые не вгоняют хаброюзеров в тоску и не заставляют их скроллить до комментариев, было принято решение разбить его на две части. В первой части мы познакомимся с основами и даже напишем (не)много кода!

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

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

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

В разработке банковского ПО данному аспекту системы уделяется наибольшее внимание. Часто, описывая отказоустойчивую систему, используют слова: Fault Tolerance, Resilience, Reliability, Stability, DR (disaster recovery). Данная характеристика — суть способность системы продолжать корректно работать при падении одной или нескольких подсистем, от которых она зависит. Я кратко опишу какие подходы могут применяться в данной области и приведу пару примеров.

Есть два основных пути в мире бизнеса: создать что-то новое и уникальное или скопировать (а если получится — и превзойти) чужой успех. Если бы вы начинали бизнес — какой путь вы бы выбрали? Что-то мне подсказывает, что большинство потенциальных стартаперов — вполне себе романтики, и копирование чужих идей их не очень-то привлекает. Тем более, что и своих оригинальных идей — полна голова, аж крышу сносит, правда?

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

Жизнь — дерьмовая штука. По крайней мере, так считают многие «взрослые» люди, с которыми мне довелось общаться. Они постоянно жалуются на свою работу, неудовлетворительные отношения и раздолбаев-детей, которые никак не хотят становиться такими, какими хотят их видеть родители. Жизнь для этих людей — это бесконечная карусель разочарований, неприятностей и несбывшихся надежд. Они встают рано утром с больной головой, заливают в рот пару литров кофе и едут на работу в состоянии, которому позавидовали бы самые отъявленные зомби. Они ненавидят свою работу и считают, что их занятия бессмысленны и никому не нужны. Но, не смотря на это, они с упорством леммингов продолжают делать эту работу, день за днём, год за годом. Они продираются сквозь собственную жизнь, надеясь, что всласть поживут потом, когда отработают 10-20-30 лет. Так вот, это всё херня. Когда вам будет пятьдесят, вы настолько устанете от такой жизни, что единственным вашим желанием будет лечь и сдохнуть. Да и здоровье будет уже не то, потому что вы слили его, занимаясь всякой ерундой, до которой вам даже не было дела. Так что, когда вы выйдете на пенсию, вы не поедете в Африку охотиться на львов, потому что солнце плохо сказывается на вашем давлении. Вы также не поедете на Северный полюс, потому что у вас артрит и холод — не лучшее для него лекарство. Южный полюс отпадает ещё и потому, что вы недолюбливаете пингвинов, что неудивительно, учитывая ваш 30-летний стаж работы сисадмином. Так что же вам остаётся? Поездки на дачу и вечера в уютной компании телевизора, вот что. Прожив 30 лет в постоянной борьбе с самим собой, у вас просто не останется сил на то, чтобы оторвать задницу от дивана.