Работал один товарищ техническим специалистом у областного интернет-провайдера под Питером. Днём на телефоне у себя дома (техподдержка), вечером – выезды к клиентам. Будучи человеком любознательным, подкованным в электронике и вообще гиком, он, настраивая интернет у клиентов, иногда брался и починить клиентский ноутбук. Знакомо? Думаю, многим здесь. Постепенно он научился чинить не только компьютеры, но и смартфоны, и прочее железо. И стало понятно, что может появиться ещё одна профессия, приносящая даже больший доход, чем основная работа.



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

Хочу рассказать о том, как мы захотели сделать собственный бекап баз данных для Microsoft SQL Server, и что из этого получилось.

Проблема

Мы в компании используем Microsoft SQL Server, и вполне ожидаемо, что нам надо делать бекапы баз данных для него, что мы успешно делаем. Делается это следующим образом:

• Первый скрипт делает бекапы нужных баз данных
• Второй скрипт проходит по папкам с бекапами и архивирует их в 7zip
• Третий скрипт уносит эти бекапы на внешнее хранилище

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

… и функциональное программирование тоже.

Так получилось, что, несмотря на знакомство со множеством парадигм и техник программирования, я не придерживаюсь строго ни одной из них. Впрочем, и ни одну из них не считаю отстоем. Почему?

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

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

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

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

Эта статья о том, как построить архитектуру web-приложения в соответствии с принципами MVC на основе React и Redux. Прежде всего, она будет интересна тем разработчикам, кто уже знаком с этими технологиями, или тем, кому предстоит использовать их в новом проекте.

Всё, что вы рендерите в Three.js, по умолчанию отображается на экране. Зачем вообще нужен рендеринг, если нельзя увидеть результат? Оказывается, затем, чтобы собрать данные, прежде чем они выведутся на экран (и, следовательно, будут утеряны). Это намного упрощает применение эффектов постобработки, таких как коррекция/искажение цветов и размытие изображения, а также очень полезно для шейдерных эффектов. Такой прием называется рендеринг в текстуру или рендеринг в буфер кадра. Конечный результат сохраняется в текстуре, которую затем можно отобразить на экране. В этой статье я покажу, как это делается, на конкретном примере рендеринга анимированного куба на поверхность другого анимированного куба.

Так уж вышло, что запуск cron в Docker-контейнере — дело весьма специфическое, если не сказать сложное. В сети полно решений и идей на эту тему. Вот один из самых популярных (и простых) способов запуска:

cron -f

Но такое решение (и большинство других тоже) обладает рядом недостатков, которые сходу обойти достаточно сложно:

• неудобство просмотра логов (команда docker logs не работает)
• cron использует свой собственный Environment (переменные окружения, переданные при запуске контейнера, не видимы для cron заданий)
• невозможно нормально (gracefully) остановить контейнер командой docker stop (в конце концов в контейнер прилетает SIGKILL)
• контейнер останавливается с ненулевым кодом ошибки

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

Я уверен, что многим программистам знакома формула:


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

Вычисляет она относительную яркость цвета (relative luminance или в некоторых контекстах luma; не путать с lightness и brightness) и широко применяется для преобразования цветного RGB-изображения в Grayscale и связанных с этим задач.

Формула растиражирована и процитирована в тысячах статей, форумных обсуждений и ответов на StackOverflow… Но дело в том, что единственно-правильное её место — на свалке истории. Использовать её нельзя. Однако же используют.

Но почему нельзя? И откуда же взялись именно такие коэффициенты?

Азбука безопасности Ubuntu

«Мои первые 5 минут на сервере» Брайана Кеннеди — отличное введение, как быстро обезопасить сервер от большинства атак. У нас есть несколько исправлений для этой инструкции, чтобы дополнить ею наше полное руководство. Также хочется подробнее объяснить некоторые вещи для более юных инженеров.

Каждое утро я проверяю почтовые уведомления logwatch и получаю основательное удовольствие, наблюдая несколько сотен (иногда тысяч) безуспешных попыток получить доступ. (Многие довольно прозаичны — попытки авторизоваться как root с паролем 1234 снова и снова). Приведённая здесь общая методика подходит для серверов Debian/Ubuntu, которые лично мы предпочитаем всем остальным. Они обычно служат только хостами для контейнеров Docker, но принципы те же.

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

Примечание: Эта справка создана как базовая азбука. Её следует расширить и дополнить в соответствие с вашими потребностями.

Эта статья — третья часть серии:

• Часть 1: Декораторы методов
• Часть 2: Декораторы свойств и классов
• Часть 3: Декораторы параметров и фабрика декораторов
• Часть 4: Сериализация типов и metadata reflection API

В прошлый раз мы узнали, что такое декораторы и как они реализованы в TypeScript. Мы знаем, как работать с декораторами классов, свойств и методов.

В этой статье мы расскажем про:

• Последний оставшийся тип декораторов — декоратор параметра
• Реализацию фабрики декораторов
• Реализацию конфигурируемых декораторов

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

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

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

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

Например, вот ситуация: наш контрагент когда-то был гражданином Казахстана, и у него было отчество. В этот момент русский банк открыл ему счёт. Потом он сменил паспорт на русский, и отчество у него пропало. Вообще. Просто стал человек без отчества. В итоге мы сначала пытались это расчухать (бухгалтерия не пропускала документ, видя явный косяк в неполном ФИО), а потом, когда разобрались, банк ещё и отменил первый перевод – потому что у них-то человек с отчеством, а мы шлём на такого же, но без отчества. И без вариантов. Счёт ему в итоге пришлось открывать в другом банке.

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

Всем кому интересно, добро пожаловать под кат.

Не знаю почему, но информации об этом новом класса в .NET Framework, действительно немного. Документация MSDN почти ничего не говорит о способах использования SynchronizationContext. Должен сказать, изначально я и сам плохо представлял назначение этого класса и как его использовать. После продолжительного изучения вопроса я наконец понял его назначение и решил написать эту статью чтобы помочь разобраться другим разработчикам.

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

Выложить проект с открытым программным кодом – это больше, чем выложить код в Интернете.

Интерес к программным продуктам с открытым исходным кодом растёт последние 10 лет. Linux стоит и в стиральных машинах, и в боевых дронах. Большинство программистов не могут представить свою жизнь без широкого ассортимента бесплатных и открытых инструментов в своем распоряжении.

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

Чем вы можете помочь своему проекту, чтобы его заметили?

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

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

Сегодня многие технологические компании обращают пристальное внимание на технологию контейнеров. В их числе – Google, IBM, Microsoft и конечно HPE. Контейнеры позволяют «упаковать» в один физический сервер намного больше приложений, чем это позволяют сделать виртуальные машины. Контейнерные технологии не новы, например, многие знают о них по разработкам компании Parallels, но они играют все более важную роль в центрах обработки данных и облаках. О них и пойдет речь.


^{Немножко не те контейнеры, о которых речь, но надо же привлечь внимание :)}

Как и многие компании мира высоких технологий, компания Hewlett Packard Enterprise занимается венчурными инвестициями. Один из недавних примеров – инвестиции в разработчика лидирующих на рынке программно-определяемых объектных хранилищ Scality. Другой пример инвестиций в передовые технологии – поддержка стартапа Mesosphere, разработчика так называемой DC/OS.

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

Если вкратце, то проект из себя представляет несколько БД и приложений, расположенных на разных серверах. «Задача» в данном проекте – это хранимая процедура или .Net приложение. Соответственно «задача» должна быть выполнена на определённой БД и на определенном сервере.

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


Фотку взял с Yaplakal