Информационный портал по безопасности

Дисклеймер: всему сказанному ниже «верить нельзя не верить»… Запятую поставьте сами.

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

Сталкиваясь с автоматизацией, часто приходится слышать о «волновой сборке» и «волнах заказов». Для начала, маленькая вводная о том, каким образом появился термин «волна». Представим себе график, где по оси X – время, а по оси Y – некоторый показатель. Мы ждем, пока значение показателя по оси Y не увеличится до заданной максимальной величины, и начинаем выполнять действия, приводящие к уменьшению значения. Затем, «упав» до заданного минимального значения, снова ждем накопления. Таким образом, у нас появляется график в виде своеобразных «волн». Приведу простой пример, когда использование таких «волн» нам может быть выгодно при сборке заказов:

Впервые рабочая группа IEEE 802.11 была анонсирована в 1990 году и вот уже 25 лет идёт непрекращающаяся работа над беспроводными стандартами. Основным трендом является постоянное увеличение скоростей передачи данных. В данной статье я попробую проследить путь развития технологии и показать, за счёт чего обеспечивалось увеличение производительности и чего стоит ждать в ближайшем будущем. Предполагается, что читатель знаком с основными принципами беспроводной связи: видами модуляции, глубиной модуляции, шириной спектра и т.д. и знает основные принципы работы Wi-Fi сетей. На самом деле существует не так много способов увеличения пропускной системы связи и большинство из них было реализовано на разных этапах совершенствования стандартов группы 802.11.

Ранее я писал, как включить поддержку jsonb в postgres/psycopg2. Сегодня экспериментировал с тем, как запрашивать данные в колонках типа JSON.
На эту тему есть документация, но мне было не совсем понятно, как работают различные операции:

CREATE TABLE json_test (
  id serial primary key,
  data jsonb
);

INSERT INTO json_test (data) VALUES 
  ('{}'),
  ('{"a": 1}'),
  ('{"a": 2, "b": ["c", "d"]}'),
  ('{"a": 1, "b": {"c": "d", "e": true}}'),
  ('{"b": 2}');

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

Креш происходил стабильно при заходе в папку с корейскими символами. Проблема оказалась во вроде бы безобидном коде следующего вида:

NSURLComponents* urlComp = [[NSURLComponents new] autorelease];
...
urlComp.path = path;
urlComp.user = username;
...

В Cache есть несколько различных способов пройтись по коллекции и выполнить какие-нибудь действия с ее элементами. Самым простым является while-цикл. Такой способ позволяет решить поставленную задачу в императивном стиле. Разработчику приходиться явно заботиться об итераторе, о переходе к следующему элементу и о проверке выхода за пределы коллекции.
Но разве это то, о чем должен заботиться разработчик?! Разработчик должен решать поставленную перед ним задачу, за максимально короткое время с максимально хорошим качеством кода. Было бы очень здорово просто взять коллекцию и применить к ней функцию, которая выполняет необходимые действия на каждом элементе этой коллекции. Не проверять границ, не создавать итератор, не вызывать вручную функцию на каждом элементе. Такой способ решения задач называется декларативным программированием.
(c) 1800-information
Давайте подумаем, как же решить поставленную задачу декларативно, используя средства и возможности Cache.

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

Вообще для чего обычно используют составные файлы?
Для всего, что нужно хранить в некоем контейнере (NoSQL подмножество).
К примеру, файлы старых версий Microsoft Office от 97 до 2003 включительно (состоящие на самом деле из нескольких десятков файлов), хранились как раз в составном файле. Сейчас тоже хранятся, только в качестве контейнера используется ZIP.

Инсталляционные пакеты MSI тоже являются составными файлами, и даже файл кэша эскизов папок Thumbs.db использует этот формат.

Правда для того же Word есть целый комплекс утилит (Recovery for Word, Word Recovery Toolbox, Munsoft Easy Word Recovery) восстанавливающих, ну или по крайней мере пытающихся восстановить, поврежденные документы. Выводы можете сделать сами.
Хотя, при должной работе с составными файлами проблему их повреждения можно решить (и я покажу как).

Ну и, конечно же, несомненным плюсом этого формата является то, что внутри хранилища эмулируется полноценная файловая система со своими файлами и папками.

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

Здравствуйте.

Многим наверняка приходилось в своей жизни проектировать и разрабатывать RESTful API. С релизом технологии Web API делать это стало гораздо проще, а с выходом Web API 2 еще и куда приятней. Система раутинга, перекочевавшая из ASP.NET MVC, отлично справляется со своей задачей, и позволяет нам не только свободно конструировать пути, но и приправлять их различными параметрами, указывая оные в фигурных скобках. Вряд ли шаблон вида «api/{controller}/{id}» вызывает нынче у кого-то благоговейный ужас. Однако что произойдет, если какой-то из методов нашего API в качестве этого самого {id} будет принимать не число в строковом представлении, не Guid, а, скажем, адрес электронной почты? Ну, например, чтобы проверить наличие этого адреса в базе данных. Работать тогда ничего не будет, а виной всему маленькая и, казалось бы, совсем безобидная точка. Как с этим жить дальше и рассказывается под катом.

Разница между продуктом и проектом в том, что при разработке продукта есть план, а при разработке проекта есть исследования. Если у вас есть какая-то не решённая проблема, скажем вы ещё не решили какую базу данных использовать в своём проекте, то вам понадобится этот вопрос изучать, то есть исследовать. Это называется technology research. Исследование, это вовсе не обязательно, что-то совершенно новое в мировом масштабе, если вы строите мост, то вам надо исследовать грунт в данном конкретном месте, и пока этот грунт не исследован, мост, как продукт, ещё не существует, пока что это — проект. Ещё не известно, какой грунт, а значит не известно из чего делать мост, как его укреплять, невозможно посчитать бюджет и распланировать график работ.

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

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