Я работаю в коммерческой разработке с 2011 года. С конца 2012 занимаюсь разработкой под iOS. Свою первую техническую статью я написал на Хабре в начале 2017 года про подход к локализации мобильных приложений. Потом выпустил ещё несколько статей по iOS-разработке на Хабре и в конце 2017 года я перешёл в новую компанию и решил вести блог про solution architecture https://medium.com/@nvashanin, где начал описывать общие концепты, обязанности архитектора, его скилл-сет и т.д. К лету 2020 года количество просмотров моих статей перевалило за 800 тысяч, а количество времени, которое люди потратили на прочтение — больше 6 млн минут, или около 12 лет чистого времени. Флагманская статья была переведена другими людьми на разные языки: например, польский или испанский.

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

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

Основные проблемы, которые встречаются в библиотеках валидации данных

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

Проблема №2. Процедурное описание правил валидации. Я не хочу каждый раз думать про алгоритм валидации, я просто хочу описать декларативно, как должны выглядеть правильные данные. По сути, я хочу задать схему данных (почему не «JSON Schema» — в конце поста).

Проблема №3. Описание правил валидации в виде кода. Казалось бы, это не так страшно, но это сразу сводит на нет все попытки сериализации правил валидации и использования одних и тех же правил валидации на бекенде и фронтенде.

Проблема №4. Валидация останавливается на первом же поле с ошибкой. Такой подход не дает возможности подсветить сразу все ошибочные/обязательные поля в форме.

Проблема №5. Нестандартизированные сообщения об ошибках. Например, «Field name is required». Такую ошибку я не могу показать пользователю по ряду причин:

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

То есть, нужно возвращать не сообщение об ошибках, а стандартизированные коды ошибок.

Проблема №6. Числовые коды ошибок. Это просто неудобно в использовании. Я хочу, чтобы коды ошибок были интуитивно понятны. Согласитесь, что код ошибки «REQUIRED» понятней, чем код «27». Логика аналогична работе с классами исключений.

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

Проблема №8. Ограниченный набор правил. Стандартных правил всегда не хватает. Валидатор должен быть расширяемый и позволять добавлять в него правила любой сложности.

Проблема №9. Слишком широкая сфера ответственности. Валидатор не должен генерировать формы, не должен генерировать код, не должен делать ничего, кроме валидации.

Проблема №10. Невозможность провести дополнительную обработку данных. Практически всегда, где есть валидация, есть необходимость в какой-то дополнительной (часто предварительной) обработке данных: вырезать запрещенные символы, привести в нижний регистр, удалить лишние пробелы. Особенно актуально — это удаление пробелов в начале и в конце строки. В 99% случаев они там не нужны. Я знаю, что я до этого говорил, что валидатор не должен делать ничего кроме валидации.

3 года назад, было решено написать валидатор, который не будет иметь всех вышеописанных проблем. Так появился LIVR (Language Independent Validation Rules). Есть реализации на Perl, PHP, JavaScript, Python (мы на python не пишем — фидбек по ней дать не могу). Валидатор используется в продакшене уже несколько лет практически в каждом проекте компании. Валидатор работает, как на сервере, так и на клиенте.

Доброго Нового Года!

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

Пусть имеется набор N из n целых положительных чисел от 1 до n.
Самоочевидно, что для хранения n чисел необходимо иметь n ячеек. Вне зависимости от порядка, в котором числа будут записаны.

Исходный массив

3

5

2

1

8

4

7

6

9

10

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

Упорядоченный массив

1

2

3

4

5

6

7

8

9

10

Хабралюди, добрый день!
Сегодня хочу начать написание ряда лекций с практическими заданиями по книги Михаеля Привата и Роберта Варнера «Pro Core Data for iOS», которую можете купить по этой ссылке. Каждая глава будет содержать теоретическую и практическую часть.



Содержание:

• Глава №1. Приступаем (Практическая часть)
• Глава №2. Усваиваем Core Data
• Глава №3. Хранение данных: SQLite и другие варианты
• Глава №4. Создание модели данных
• Глава №5. Работаем с объектами данных
• Глава №6. Обработка результатирующих множеств
• Глава №7. Настройка производительности и используемой памяти
• Глава №8. Управление версиями и миграции
• Глава №9. Управление таблицами с использованием NSFetchedResultsController
• Глава №10. Использование Core Data в продвинутых приложениях

Извечная мечта «ничего не делать и получать за это деньги» наконец-таки стала доступна не только депутатам.

Мир bitcoin мощными рывками захватывают суперспециализированные устройства для майнинга — ASIC майнеры.

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

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



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

На сегодняшний момент ASIC чипы производятся по 55нм-65нм технологии в США и Китае. Однако уже несколько компаний анонсировали 28нм чипы, которые будут готовы в конце этого года или в начале следующего. Это увеличит мощности ASIC устройств в сотни и тысячи раз, поэтому можно смело запасаться попкорном — 2014 год будет зрелищным.

<далее будет про отечественный ASIC майнер BitFury от Метабанка>

Здравствуйте, дорогие читатели Хабра!

Я разрабатываю приложения под iOS и Mac OS. Уже около года занимаюсь фрилансом и, переходя от клиента к клиенту, начал замечать, что в задаче разбираюсь одиножды; а при появлении похожего заказа, просто использую уже разработанные ранее модули. В серии статей «Записки iOS разработчика» я постараюсь осветить некоторые часто встречающиеся в заказах аспекты; напишу подобие шпаргалки, прочитав которую, вы сможете быстро и безболезненно внедрить новую технологию в свой проект. Мои заметки ни в коем случае не претендуют на глубокое понимание процессов, но описывают легкий способ закончить заказ в срок.

Содержание:

1. Часть 1: Работа с Файлами; Шаблон Singleton; Работа с Аудио; Работа с Видео; In-App Purchases
2. Часть 2: Собственные всплывающие окна (Popups); Как использовать Modal Segue в Navigation Controller; Core Graphics; Работа с UIWebView и ScrollView
3. Часть 3: Жизнь без Autolayout; Splash Screen; Работа с ориентацией девайса в iOS 6+; Сдвиг содержимого UITextField
4. Часть 4: Google Analytics; Push Notifications; PSPDFKit; Вход в приложение через Facebook; Рассказать друзьям — Facebook, Twitter, Email
5. Часть 5: Core Data; UITableView и UICollectionView

Я, как человек более 7 лет проработавший фрилансером, и выросший из фрилансера в небольшую IT компанию из 10 человек. Не мог пройти мимо весьма познавательной статьи: 10 советов для заказчика во фрилансе.

И с позволения, написал свой ответ, так сказать, Чемберлену. С точки зрения фрилансера.

Думаю, что большинству разработчиков под iOS известно как легко включить iTunes File Sharing в своем приложении, добавив лишь одну строчку в Info.plist:

UIFileSharingEnabled = YES

Но это даже не полдела. Соль в том, что, по-хорошему, приложение теперь должно остлеживать все изменения с файлами, происходящие в директории Documents и соответственно обновлять свои данные. Как это релизовать в своём коде и расскажет данная статья.

Здравствуйте, дорогие читатели Хабра!
Эта статья — вторая часть серии «Записки iOS разработчика».

Содержание:

1. Часть 1: Работа с Файлами; Шаблон Singleton; Работа с Аудио; Работа с Видео; In-App Purchases
2. Часть 2: Собственные всплывающие окна (Popups); Как использовать Modal Segue в Navigation Controller; Core Graphics; Работа с UIWebView и ScrollView
3. Часть 3: Жизнь без Autolayout; Splash Screen; Работа с ориентацией девайса в iOS 6+; Сдвиг содержимого UITextField
4. Часть 4: Google Analytics; Push Notifications; PSPDFKit; Вход в приложение через Facebook; Рассказать друзьям — Facebook, Twitter, Email
5. Часть 5: Core Data; UITableView и UICollectionView

Разберемся с кастомизируемыми всплывающими окнами в конце статьи, так как это довольно обширная тема. А пока что — все остальное.

На фото — Jalapeno, каким он должен был быть изначально.

Покупка.

В ноябре прошлого года я сделал предзаказ Jalapeno у Butterfly Labs. У них также было несколько других, более дорогих майнеров, но мой выбор пал именно на этот из-за цены в 150 долларов США + $38 за доставку до России. В характеристиках значились 4.5 GH/s – огромная производительность за эти деньги. Например, AMD Radeon 6990, стоившая на тот момент $700, выдавала всего 750 MH/s, да еще и потребляла в 10 раз больше электричества (375W против 30W). Сей девайс мне обещали отправить в январе 2013 года.

Доставка.

Время шло, но BFL все тянули и тянули сроки. До марта я регулярно проверял их сайт, находя новости о задержках. Вскоре о своей покупке я совсем позабыл, пока не получил письмо счастья 26 июля с треком. С нетерпением прождав месяц, я наконец-то забрал свой девайс с почты. Открыв коробку, я обнаружил, что устройство отличается от фотографий, что были на сайте. Майнер стал намного толще, но это меня нисколько не огорчило. Тяжелая черная коробка выглядела более надежно, чем плоский блин, что был на фото. Выяснилось, что железка не влезала в старый корпус, и его пришлось поменять. Первым делом я полез на сайт за драйверами, и, к своему удивлению, не обнаружил нужной мне модели на сайте производителя. Вместо нее красовался BitForce 5 GH/s Bitcoin Miner, который внешне не отличался от моего. Я так и не понял, то ли мне выслали Jalapeno, но в новом корпусе, то ли 5 GH/s майнер. А может быть это одно и тоже устройство? В документах, которые шли с посылкой, значился 4.5 GH/s Jalapeno, а на деле устройство выдавало 5 GH/s. Но обо всем по порядку.

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

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

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

Под катом набор инструментов для аналитики и рекомендации по их настройке принятые в Touch Instinct и ценные комментарии от LinguaLeo и агентства мобильной рекламы Mobio.

Apportable SDK — это продукт, который позволяет без изменений скомпилировать игру (или приложение), разработанное на Objective-C/Cocoa Touch для iOS под Android. Это полный toolchain (компилятор, дебаггер, линковщик — все-все-все), работающие Foundation, CoreFoundation, UIKit, множество других фреймворков из состава iOS, перенесенные на Android (даже такая «мелочь» как GameKit и StoreKit, с бэкендами для GooglePlus и Amazon GameCircle/Appstore).

Цель Apportable — дать iOS разработчику перенести свое приложение на Android за час, без изменения кода, и поддерживать после этого одну кодовую базу. Как портировать простую игрушку на cocos2d — под катом

Поясню для начинающих, что при разработке под iOS для установки на девайс большую часть времени вы собираете приложение в development режиме, т.е. только для себя.
Но в какой-то момент требуется начинать выдавать заказчику результат работы на «посмотреть».
Для этого используется особый вид сборки AdHoc Distribution. Нужно сходить к Apple'у и создать distribution provisioning profile. После чего собирать приложение, подписывая его этим профилем. В профиле прописываются все идентификаторы девайсов, на которые планируется это приложение устанавливать на этом этапе. В итоге при билде под AdHoc, XСode создает файл с расширением .ipa, который уже можно установить на все, прописанные в профиле, девайсы. Например через iTunes.

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

Об одном из таких способов, с автоматизацией выдачи из Xcode читаем под катом!

Что это?

πfs это революционная файловая система, которая вместо того, чтобы тратить место на вашем жестком диске, хранит все данные в π. Вам никогда больше не придется заботится о свободном месте! Вам говорили, что 100% сжатие невозможно? Да вот же оно!

Как собрать?

πfs собирается элементарно:

./configure
make

Да и использовать его не сложнее:

πfs -o mdd=<metadata directory> <mountpoint>

Где metadata directory — каталог с метаданными (названия файлов, смещение в π), а mountpoint ­— каталог монтирования.

Что же π делает с моими данными?

π — одна из самых важных констант математики, и у нее есть куча интересных свойств (о которых можно прочесть в статье на википедии)
Одним из таких свойств числа π предположительно является нормальность, что означает, что все его числа распределяются равномерно, при условии, что это дизъюнктивная последовательность, т.е. все конечные числовые последовательности находятся внутри него. Если мы рассмотрим число π по основанию 16 (HEX), то это предположение верно. Первая запись об этом была в 2001 году.
Ну а если так, то зачем нам хранить все эти эксабайты данных на винчестерах, если мы можем найти их в π?

Мне бы хотелось рассказать об интересном опыте, приобретенном в процессе разработки бесплатного пока что конвертера валют, моего второго приложения в категории Finance. Первое, Money iQ, было написано во время работы в небольшой компании и даже успело побывать на 1м месте российского App Store. Небольшую dev story о создании приложения я опубликую чуть позже и в другом блоге, если будет интересно, а в этой статье мне хотелось бы остановиться на такой проблеме как мгновенное изменение языка внутри приложения.

Собственно, проблема.

Наверное, многим приходилось сталкиваться с мультиязычными приложениями. Я говорю не только о приложениях под iOS, а вообще о приложениях, поддерживающих несколько языков. Во из них в сеттингах есть пункт «Language/Язык/Idioma», позволяющий установить язык, нужный пользователю.

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

Предисловие

Об этом самоучителе

Добро пожаловать в «Азы администрирования», второе из четырех обучающих руководств, разработанных чтобы подготовить вас к экзамену 101 в Linux Professional Institute. В данной части мы рассмотрим как использовать регулярные выражения для поиска текста в файлах по шаблонам. Затем, вы познакомитесь со «Стандартом иерархии файловой системы» (Filesystem Hierarchy Standard или сокр. FHS), также мы покажем вам как находить нужные файлы в вашей системе. После чего, вы узнаете как получить полный контроль над процессами в Linux, запуская их в фоновом режиме, просматривая список процессов, отсоединяя их от терминала, и многое другое. Далее последует быстрое введение в конвейеры, перенаправления и команды обработки текста. И наконец, мы познакомим вас с модулями ядра Linux.

В частности эта часть самоучителя (Часть 2) идеальна для тех, кто уже имеет неплохие базовые знания bash и хочет получить качественное введение в основные задачи администрирования Linux. Если в Linux вы новичок, мы рекомендуем вам сперва закончить первую часть данной серии практических руководств. Для некоторых, большая часть данного материала будет новой, более опытные же пользователи Linux могут счесть его отличным средством подвести итог своим базовым навыкам администрирования.