Pull to refresh
33
0

Управление проектами в IT

Send message
Я смотрю БАЙТ в Беларуси много людей подтолкнул к программированию. Начало моей истории очень похоже)
С помощью Brain training программ можно смотреть графики состояния своего сознания. Я почти не пью алкоголь, видимо поэтому, несколько лет назад на д.р. довольно сильно накидавшись и пройдя на следующий день тесты обнаружил, что мои способности упали почти в 2 раза. Восстановление к моим обычным показателям заняло целых 5 дней! Когда Вы проходите тесты каждый день, то в какой-то момент доходите до своего максимума и каждый день показываете одинаковые результаты, поэтому можно очень точно определять как события из Вашей жизни влияют на Ваши способности. Интересно, что свои максимальные результаты я достиг в состоянии сильнейшей усталости после ночного перегона яхты.
На сайте Lumosity есть интересная статья по поводу влияния алкоголя на способности к обработке информации, пространственному восприятию и математическому расчету.Cамые высокие показатели во всех трех играх показали те, кто пил 1 или 2 напитка в день. Эта группа даже превзошла трезвенников, что было неожиданным открытием.image

Как будто проблемы разработчиков никто не должен решать (вот та же история с перекрытием сетей — думаете, что она не пьет кровь девам?). А они зачастую не в состоянии это сделать, т.к. у них фокус не на админстве.


CI и пр. Production ready это k8s (или его «мини» версии, типа mikrocube или k3s)

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


За упоминание k3s — жирный плюсик. Спасибо

Вобщем автор хочет, чтобы резюме были написаны по методу STAR, который создает темы для разговоров. Наверное скоро это станет негласным правилом, писать резюме по шаблону STAR, т.к. демонстрирует как hard-skills, так и soft-skills
image
Сам стараюсь придерживаться данного метода, но с некоторыми местами работы не всегда виден результат, напрямую выраженный как в прибыли для компании, так и для себя, например работая в крупной корпорации, где вклад отдельного человека не так заметен и затруднительно это выразить в количественных оценках.
Я пробовала www.italki.com — там можно искать нейтивов, которые сами назначают цену за занятие. Получается гораздо дешевле всяких скайенгов и тп.
Я год назад покупал, протухла ссылка. Но и сейчас нашел за 7806,94, ссылку на дам, ибо модерация, а вот название — «HT-175 Imager Цифровой Инфракрасный Тепловизор инфракрасный термометр-20-300 градусов 32X32». Им нормально исследовать утечки тепла или нагрев проводки изнутри дома, но снаружи целиком дом видно плохо — непонятно, что где, тут лучше брать в двумя камерами — типа HT-02D. Вот, кстати, новые появились — приставки к смартфонам — HT-102, типа FLIR ONE, но похуже, конечно. С двумя камерами и 7225р. «HT-102 мобильный телефон внешний Инфракрасный Тепловизор инфракрасный Камера термометр Android телефон OTG функция с адаптером»
Я, кстати, вот про это атомарное обновление не нашел, хороший момент. С другой стороны — раз уж мы говорим про http — то есть https://github.com/fvbock/endless который как раз и делает атомарное обновление — им мы на работе и пользуемся чтобы там, имея тысячи запросов в секунду к бэкэнду — без потерь запросов обновлять код.
Лично сам не переходил на Go и из этого с серьезными проблемами не сталкивался. Но когда узнал, что в Go есть «зеленые процессы» и обмен сообщениями между ними, то решил узнать об этом подробнее. Все что я узнавал, я критически оценивал в контексте знаний об Erlang. В итоге хотел даже написать какой-нибудь веб сервер и на том и на другом, потом померяться, написать статью. Но потом поуспокоился и эту идею отложил до лучших дней.

В общем, мои скромные изыскания в части сравнения реализации процессов и способов обмена данными между ними, выявили следующее:

1. Обмен сообщениями.
В Go для обмена сообщениями используются каналы. Канал явно существует, как понятие. Он передается в функцию (горутину), а та уже с ним работает.
Что понравилось:
— вроде бы можно одно сообщение из канала принять двумя корутинами
Что не понравилось:
— необходимость самого существования такого понятия, как канал (в ерланг это не надо)
— при отправке сообщения в канал, отправляющий процесс «зависает» пока принимающий не примет данные. Для чего такое может быть нужно, мне сложно понять. В итоге, может выстроиться цепочка из процессов от соединения с пользователем, до записи на диск, и вся она «зависнет» на работе с файловой системой. Но в принципе, на сколько мне сумели объяснить, в таких случаях сообщения «принимают и складывают на стек», читай принимают и складывают в память процесса. Чтобы устранить зависания, в канале может быть включен буфер ФИФО, это от части решает проблему с зависанием.

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

Вопрос того, что в Erlang процесс обмена сообщениями внутри ноды или кластера происходит прозрачно, тут не обсуждаем. Приложения Go в кластер не объединяются. Там своя тема под названием микросервисы и то, как они меж собой связаны уже решает разработчик, но пусть так. Из положения выходят с помощью grpc или как-то иначе. Но для меня до сих пор остается загадкой, как множество процессов одного приложения, например tcp соединений с клиентами, должны обмениваться с процессом, например, базы данных? Сколько будет каналов, как их столько держать и обрабатывать? В Erlang даже вот чисто концептуально все это получается менее нагроможденным и простым. Процесс клиент просто отправит сообщение серверу, в сообщении будет PID, куда слать ответ. Сервер процесс не хранит всю связность с процессами — клиентами. Очередность будет соблюдена благодаря тому, что сообщения в почтовом ящике процесса выстраиваются в очередь. В то же время, есть возможность выбрать сообщения в другом порядке.

2. Зеленые процессы. В Erlang всё понятно — это виртуальная машина, она выполняет байткод, каждый процесс выполняется на заданное количество редукций, разрешенных для него, потом, что бы он не делал (за исключением атомарных операций), он будет прерван и выполняться будет уже другой процесс. Распределяет работу шедулер. Из коробки ноду Erlang можно считать целой ОС мягкого реального времени.

Я грешным делом сначала подумал и возрадовался, что в Go для реализации работы горутин используется что-то типа встроенной виртуальной машины. Это было бы шикарно: виртуальная машина в приложении. Но в процессе общения в Go'шном канале (ребятам, кстати, спасибо), выяснилось, что никакой виртуальной машины нет. Но как же работают горутины в параллельном режиме? Как осуществляется шедулинг? Оказалось, что если создать горутину, которая в бесконечном цикле прибавляет единицу и никуда это не передает, то она «зависнет» насовсем. И если запустить Go приложение в один процесс (а не по умолчанию 6 — 8), то приложение зависнет насовсем с момента запуска горутины и то, что будет после этого, никогда не выполнится! Я даже сделал ошибочный вывод о том, что на одноядерном процессоре это все в принципе может перестать работать. Но потом вспомнилось про системные threads и что они существуют как бы параллельно даже на одном ядре. Так что, приложение Go вполне себе честно виснет, будучи запущенным в один процесс, если горутина зациклена. Открытием было то, что передача управления на другие горутины происходит при вызове функций других модулей (просто, или, к примеру, вывода на экран). То есть, ничего общего с равномерным распределением ресурсов тут получается, что и нет. Каждый процесс может неопределенное время монопольно использовать один thread, пока не отпустит. В условиях того, что thread'ов выделяется несколько, то это бросается в глаза как бы не сразу. Все это напоминает многозадачность Win95, когда задачи сами решали, когда отдать управление ОС. На сколько мне известно, решение о том, какую горутину выполнять дальше, решает рандом. И вообще это еще в процессе разработки, потому что этот алгоритм показал плохие результаты. Другие статьи по Go вполне ожидаемо сообщают о том, что не всегда целесообразно создавать много параллельных горутин.

3. Производительность. Перед тем, как сделать простой веб сервер на Go и на Erlang и сравнить их по производительности, я взял задачу, которая гарантировано удобнее для Go. Это счастливые билетики. Тупо в лоб 6 вложенных циклов от 0 до 9 и миллион итераций сравнения. Естественно, Go обогнал Erlang больше, чем на порядок. Потом я скомпилировал модуль Erlang с применением HiPE и расчет на Erlang оказался в 4 раза медленнее расчета на Go.

На этом я и остановился. Ощутимой прибавки производительности можно и добиться, но другие минусы расстроили. А целого ряда возможностей Erlang'а нет и скорее всего никогда не будет в Go. Поэтому Erlang и дальше для меня остается более предпочтительным в качестве платформы для разработки серверных приложений. Серьезные проблемы типа дедлоков в нем решаются вообще иной организацией построения приложений и иным подходом в решении задач. А Go это такой же язык, как и сотня других. Простой синтаксис и компиляция в двоичный код спасают скоростью своей работы. Но на этом пока и все. Реализация зеленых процессов и обмен сообщений между ними произвели впечатление каких-то сырых костылей, скрученных изолентой. Еще в процессе обсуждения в канале нашлась еще одна задача, которая тяжело решается на Go из за его принципиально статической природы: это прием и разбор json если он не имеет строго определенной структуры (мап, а в нем мап, а в мапе тоже мап, а может и нет). Так что можно предположить, что с парсингом xml, html там могут быть похожие проблемы. Так же есть информация, что http сервер на Go оптимальнее всего работает в один процесс. Тогда зачем все эти зеленые процессы и каналы?

Ну а в связи с тем, что статья про Go, я закончу на позитивной ноте. Go мне понравился тем, что я будучи совсем ничего не знающим про Go даже могу что-то понять из исходного кода. Концепт там такой, что кода больше, но зато всем понятно. Так вот — действительно общий смысл понятно. В том же Erlang многие вещи будут очень непонятны. На Go вполне удобно делать какие-то консольные утилиты (каких то wxWidgets пока не прикручено, чаще поднимают локальный вебсервер и заходят на него из браузера, но работы вроде бы идут). Полученный exe файл получается размером меньше 10 мегабайт и рядом не требуется укладывать дополнительных dll (тут мы вспоминаем приложение Qt). Есть и кросс компиляция на другие платформы. Сообщество активно, многолюдно. Каждый второй пишет какую-нибудь библиотеку для какой-нибудь задачи (csv, orm etc), которые находятся в разных состояниях готовности. Удачи в изучении и применении Go и по возможности дайте намётки на то, как бы вы поборолись с тем, за что я его ругаю ;)
Тайм менеджмент вам поможет. Начните с Глеба Архангельского.
Однако парадокс тайм-менеджмента в том, что те кому он больше всех нужен никак не найдут времени чтобы этим менеджментом заняться!
Самая большая польза от статьи была для меня в этой ссылке.
Которая привела меня к самому крутому фреймворку на Go, который я видел: Martini.
Каждый раз (приятно) поражаюсь количеству написанного на Go.
Можно еще и for (;;0) например написать. или (0;;0)
Или вовсе (;;-0)
Способы создания смайлов на Си бессчетны ;)
Код хранится в файле, где и положено. И могу вам гарантировать, что этот файл именно инклюдится средствами php, а не из БД берется.
    protected function _process($properties = null, $content = null) {
        if(!$this->isStatic()){return;}
        if(!$controller = $this->getSourceFile()){return ;}
        $modx = & $this->xpdo;
        $this->getProperties($properties);
        $resource = & $this->xpdo->resource;
        $this->_output = require_once $controller;
        $this->_processed = true;
        return ;
    }

Напомню вам, также, что на хабре нет места оскорблениям, держите себя в руках или уймите баттхерт.
Если бы вы читали больше книжек, то знали бы, что оскорблять людей можно не только словами типа «дебил», а всякими типа колкими картинками и т.п. Поясню: вы пока человек, способный писать комменты типа «Мне нравится», «Мне не нравится», «Не понимаю, объясните» и т.п., и вы мне тут картинки суете ржачные, оценивая мои комменты. Вы уверены, что имеете достаточно компетенций, чтобы оценивать? Я один из 8-ми MODX Ambassador в рунете, общаюсь напрямую с разрабами MODX-а, обо мне упоминают и в официальных релизах, и я один из 9-ти официальных разработчиков MODX Revolution.
Думаете, я это заслужил, заливая веселые картинки? Нет. И, к слову, MODX — это не единственная платформа, которую я знаю.
А чего вы добились? Я вот как-то ничего такого не заметил. Вы только картинки умеете заливать и типа ржать. Но это в моих глазах и есть признак дебилизма. И я продолжу это утверждать. И можете продолжать прекрываться правилами, и быть может даже слезно попросить чтобы меня заблокировали (и вполне даже могут заблочить), да только ума это вам все равно не добавит. Так что довольствуйтесь тем, что имеете.
Понятно что вы делаете, не до конца понятно зачем.
У обычных пользователей, которые хотели бы просто сохранить картинку у себя на машине это вызовет лишь негатив. А те, кто хочет переопубликовать все равно вытащат. Подруга как-то раз принтскрином выдергивала мангу на перевод с китайского сайта, а китайцы постарались на славу.

На странице в iframe размещалась куча абсолютно позиционированных дивов 100х100 пикселей, которым на фон через css файл в виде base64 натянуты тайлы, нарезанные из изображения.

И что толку — наскринила, перевела, опубликовала.
> сделать собственный загрузчик

В общем, с этого многие начинали. На этом же и заканчивали. Я вот сам раза 3 пытался начать писать свою ОСь, но что-то не осилил. Зато осиляли другие:

Read about VGA Resources and GRUB. You have the opportunity to let the bootloader switch to graphical mode for you before your kernel is started. A color depth of 32 will avoid you further headaches. Documents about Accelerated Graphic Cards are gifts from the gods for Klik, but they're rare.
Develop (or reuse) a small library to draw lines, fill areas, copy bitmaps and draw text out of your kernel, debug it, then integrate it in your OS.
Find a friend to make a neat logo, ask GRUB to load it as if it was a module, memcpy it to screen and voilà. You can release 0.1

wiki.osdev.org/James_T._Klik
Осторожно! Посещение ссылки черевато написанием самодельных операционных систем. С нескучными обоями и загрузчиками.
По поводу профайлинга в MySQL я как-то писал статью на хабре
http://habrahabr.ru/post/39818/
К слову, немного рекламы:
Осторожно! Реклама Почты России
UFO landed and left these words here
1

Information

Rating
Does not participate
Location
Санкт-Петербург и область, Россия
Date of birth
Registered
Activity