Всем привет.

Написал библиотеку для обучения нейронной сети. Кому интересно, прошу.

Китайцы, как правило, очень добрые люди. Проблема с ними в том, что у них совершенно другая культура и они не понимают многого, что считается нормой у нас. Как и наоборот, кстати. Они бы и рады вписаться в общество и быть вежливыми, но главное для них — понять, как это. Работает это так: они пробуют что-то сделать и, если их никто не поправляет или никто на них косо не смотрит, решают, что это допустимо. Либо же повторяют то, что делает большинство.

Мы решили помочь братскому народу освоиться в России и подготовили памятку. Она доступна по лицензии CC BY-SA. Вы можете скачать её и повесить у себя в отеле, магазине, добавить в буклет или книгу.

Вот памятка:


А теперь пояснения.

Этот доклад руководителя группы разработки ClickHouse Алексея Миловидова представляет собой обзор мало кому известных СУБД. Некоторые из них устарели, некоторые прекратили свое развитие и заброшены. Алексей обращает внимание на интересные архитектурные решения в перечисленных примерах, разбирается в их судьбе и объясняет, каким требованиям должен отвечать ваш опенсорс-проект.


— Мой доклад будет про базы данных. Позвольте сразу спросить, схема метрополитена какого города изображена на этом слайде? Все линии идут в одну сторону.

У многих неюристов при виде очередного договора страниц на 20-30 появляется некий взгляд беспомощности. Немудрено, люди много лет учатся во всём этом разбираться, а потом ещё и практикой оттачивают. Поэтому нередко договоры подписывают не читая, просто посмотрев условия оплаты. Авось пронесёт.

Но эта проблема рукотворная. Приведу аналогию. Если вам нужно быстро сделать корпоративный сайтик, то берёте Wordpress и скачиваете любую из тем. На кой вам нужен Битрикс или уж тем более собственный движок? Или, к примеру, ту же тему надо подправить, хотелок у вас появилось. Но, не хватает знаний. Эту работу сделает большинство фрилансеров из самого низкого ценового диапазона. Зачем вам спец по 50 долларов в час?

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

Почему договоры большие

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

В ней плоскость не делится на десятиугольники, вместо этого все линии расположены под углами кратными 36°. Координаты в этой системе можно записывать целыми числами, по два целых числа на горизонтальное и вертикальное направление.



Расскажу как это нарисовать.

Когда я сижу, у меня болит спина.

Это происходит уже последние 10 лет. И неважно, где я нахожусь – на работе, в ресторане, даже дома на диване. Моя поясница кричит: «Прекрати сидеть!»

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

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

Эти средства немного помогли – сначала. Но боль так и не ушла. Поэтому несколько лет назад я решила принять это как должное: сидячее положение причиняет мне боль, и так будет всегда.

Содержание

• Мнемоника БМВ
• Общие примеры
  
  • Число
  • Дата
  • Строка
  • Файл
  • Таблица в Oracle (база данных)
  • Отчет в системе
  • Мобильные приложения
    
    • Связь
    • Количество памяти
    • Диагональ устройства
    • Разрешение экрана
    • GPX пути
  • Резюме по общим примерам
• Мои примеры из практики
  Большой мышонок
  
  • Linux, Lucene, Mmap
  • Redhat 6 ≠ Redhat 7
  • Java и garbage collection
  • Wildfly
  • Логирование
  • Транслитерация
  • Oracle RAC
  
  Маленький мышонок
  
  • Пустой JSON
  • «Москва» в поле адреса
• Итого

Мнемоника — слово или фраза, которая помогает нам что-то запомнить. Самая известная мнемоника — «каждый охотник желает знать, где сидит фазан». Кого не спроси, все с ней знакомы.

А вот в профессиональной сфере все немного грустнее. Спросите товарищей, знают ли они, что такое SPDFOT или RCRCRC. Далеко не факт… А ведь мнемоники помогают нам прогнать тесты, не забыв проверить самое важное. Чек-лист, схлопнутый в одну фразу!

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

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

Сегодня я хочу поделиться с вами своей мнемоникой БМВ для исследования граничных значений. Ее можно:

• дать джуниору для общего развития в тест-дизайне;
• использовать на собеседовании — задачу «найди границу в числе» кандидат обычно решает, а вот найдет ли он границу в строке или для загрузки файла?

ДИСКЛЕЙМЕР

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

Здесь приводится опыт, который выдернул меня из состояния «читаю со словарем».



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

Возьмем такой предмет, как английский язык. Там куча понятий: 12 времен глагола, страдательный залог, причастия и т.п. Кто их ввел? Видимо, некие ученые мужи, для которых английский язык был РОДНЫМ. Они жили себе в каком-нибудь Oxford’e или в Cambridg’e и вряд ли знали русский язык.

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

Вспомните, как вы в школе изучали русский язык. Подлежащее, сказуемое, дополнение, определение… и штук 200 правил, из которых куча исключений, которые все благополучно забывают, кроме собственно учителей русского. И которые потом нужны – максимум – при разборках с бюрократическими документами («казнить нельзя помиловать»).

Английская грамматика – туда же – что-то академическое и малополезное при изучении языка с нуля. Для человека, который более-менее свободно умеет стыковать из английских слов фразу, нужно просто учить новые слова.

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

Статья ориентирована именно на таких.

Представляю вашему вниманию перевод моей статьи из блога Проекта Darling. Маленькая справка по используемым понятиям: Darwin – операционная система с открытым исходным кодом, лежащая в основе macOS, iOS и других ОС от Apple; Mach-O – бинарный формат исполняемых файлов и библиотек, использующийся в Darwin; dyld – динамический загрузчик, использующийся в Darwin для загрузки файлов Mach-O; dylib – динамически загружаемая библиотека (обычно имеет расширение .dylib).

Цель Проекта Darling – сделать возможным запуск macOS-приложений под Linux, и умение загружать бинарные файлы в формате Mach-O – один из ключевых шагов к достижению этой цели.

Исходно, Darling был выстроен вокруг собственной реализации загрузчика Mach-O и идеи транслирования вызовов между высокоуровневым Darwin API и его Linux-аналогами. С тех пор наш фокус сместился на запуск кода во всё более и более изолированном Darwin-контейнере. С тех пор как мы перешли на использование Mach-O для внутренних компонентов Darling, у нас появилась возможность использовать исходный dyld от Apple, а также собирать многие другие компоненты Darwin с открытым исходным кодом. Нам всё ещё нужен простой загрузчик Mach-O, чтобы загружать сам dyld.

Привет, Хабр! Однажды утром мне пришла в голову идея находить "исключающее ИЛИ" между координатами точки пространства и проверять полученное число на простоту. Результат такого простого алгоритма вы можете видеть на картинке. Подробнее под катом.

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

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

Пара слов от переводчика

Продолжая освещать тему std::system_error в рунете, я решил перевести несколько статей из блога Andrzej Krzemieński, который мне посоветовали в комментариях к предыдущему посту.

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

Так же хочу предупредить, что у Andrzej Krzemieński достаточно сумбурный стиль изложения, который я не стал править. Все же я выступаю в роли переводчика, а не редактора. Так что, возможно, чтобы понять некоторые тезисы придется перечитать дважды.

Александр Алексеев (Postgres Professional)

Отличный обзорный доклад конференции HighLoad++ 2016 о том, как надо проводить профилирование программного кода. О типичных ошибках, происходящих при измерениях. И, конечно, об инструментах:

— gettimeofday
— strace, ltrace, truss
— gprof
— gdb / lldb
— perf
— pmcstat
— SystemTap
— DTrace
— HeapTrack
— BPF / bcc



В начале у меня будет не слишком техническая часть, о том, как не надо делать benchmark’и.

Я наблюдаю, что люди часто делают типичные ошибки, когда делают benchmark’и. И вот первая из них…

Представлен выпуск проекта netutils-linux 2.5.0, набора утилит для мониторинга и тюнинга производительности сетевого стека Linux. Всё написано на Python (поддерживаются python 2.6+ и 3.4+) и доступно под MIT-лицензией.

Цель проекта — упростить и унифицировать процесс тюнинга сетевого стека и сетевых карт, снизив необходимость разбираться в устройстве сетевого стека для сисадминов и освободить их головы от рутинных вычислений и написания с нуля кучи одинаковых bash-скриптов.

Рекомендации для использования — наличие канала с 200+ Мбит/с, обрабатываемого Linux-based машиной, и требований к минимизации задержек и потерь.

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

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

Недавно я наткнулся на запись очень интересного выступления Саймона Пейтона-Джонса(ведущий разработчик языка Haskell) в Microsoft Research Cambridge. В нём он рассказывает студентам, как проводить научные исследования и писать статьи по Computer Science. Его мысли мне показались очень интересными, причем применимыми не только для области CS.



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

«Почему ж всё так плохо?» — каждый раз я задаюсь этим вопросом, когда приходится иметь дело с очередным кодом, продуктом или API, созданными для внутренних нужд в непрофильной организации.

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

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

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

Я занимался разработкой ПО в нескольких организациях и по разным причинам несколько раз перенабирал команду с нуля. В итоге пришел к выводу, что качество продукта зависит только от культуры разработки. Всё остальное, включая методологии и стандарты — это инструменты: они необходимы, но одних их не достаточно.

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

В этом посте пойдет речь об одной интересной фичи в C++11, которая называется делегирующие конструкторы (delegating constructors): почему она интересна, и как ее можно применить для более эффективного управления ресурсами, т.е. реализации идиомы RAII.

Продолжаем переводить крутые статьи с сайта Bytecoin.org. Сегодня — «Alternatives for Proof of Work, Part 2: Proof of Activity, Proof of Burn, Proof of Capacity, and Byzantine Generals» Рэя Паттерсона (Ray Patterson). Часть 1 можно найти тут.

PoW vs PoS: что еще?

Итак, энергоэффективность Proof of Stake – это палка о двух концах. С одной стороны, энергия-то не тратится, с другой – без этих трат модель распределенного консенсуса выглядит несколько неустойчиво.

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

Но картина начинает выглядеть по-другому, если мы говорим о криптовалюте…

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

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

В статье на примерах объясняется, как реализовать поддержку потокового ввода-вывода из стандартной библиотеки (<iostream>) для своих классов.

В тексте статьи будет часто встречаться слово «поток», что означает именно поток ввода-вывода ((i/o)stream), но не поток выполнения (thread). Потоки выполнения в статье не рассматриваются.

Введение

Потоки из стандартной библиотеки — мощный инструмент. Аргументом функции можно указать поток, и это обеспечивает ее универсальность: она может работать как со стандартными файлами (fstream) и консолью (cin/cout), так и с сокетами и COM-портами, если найти соответствующую библиотеку.

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