Программист
В этой статье я хочу рассказать о том, как я проектирую комплексные расширения для Python на Rust с использованием PyO3 и почему я принимаю те или иные проектные решения.
Наверное не будет уж очень удивительным если я тут, на IT площадке Хабра, скажу что я иногда балую себя программированием.
Основная OS у меня Linux, но иногда приходится собирать исполняемые файлы и для Windows. И естественно что перегружаться в Windows только для сборки exe не особо хочется. С языками C и C++ проблем нет, давно существует кросскомпилятор MinGW, который прекрасно с этим справляется. Про Python и Java даже упоминать не стоит, кроссплатформенность в них изначально. Но в прошлом году я решил попробовать такой пока что новомодный язык, как Rust. При сборке исполняемого файла при помощи включённого в дистрибутив Rust пакетного менеджера cargo вроде как достаточно задать ключ --target, при помощи которого указать результирующий процессор, архитектуру и ABI и при сборке из Linux в результате получить exe, который будет являться стандартным исполняемым файлом для Windows. Но пытаясь так сделать:
cargo build --target x86_64-pc-windows-gnuя получил только сообщения об ошибках линкера:
error: linking with `gcc` failed: exit code: 1
[...]
= note: /usr/bin/ld: unrecognized option '--nxcompat'
/usr/bin/ld: use the --help option for usage information
collect2: error: ld returned 1 exit status
error: aborting due to previous error
error: could not compile `foobar`.Если кому интересно как я это поборол и теперь спокойно могу кросскомпилировать программы на Rust для Windows, не покидая Linux, добро пожаловать под кат.
Расшифровка доклада 2016 года Виталия Левченко "Prometheus мониторинг микросервисных приложений"
Prometheus, в отличие от классических систем, даёт возможность легко поднять и поддерживать мониторинг быстро меняющихся и сложно организованных систем. Я расскажу об опыте внедрения, подводных камнях и неожиданном поведении, покажу способы быстрой конфигурации всей системы, включая уведомления и дашборды.
Одним из нововведений в Go 1.9 было добавление в стандартную библиотеку нового типа sync.Map, и если вы ещё не разобрались что это и для чего он нужен, то эта статья для вас.
Для тех, кому интересен только вывод, TL;DR:
если у вас высоконагруженная (и 100нс решают) система с большим количеством ядер процессора (32+), вы можете захотеть использовать sync.Map вместо стандартного map+sync.RWMutex. В остальных случаях, sync.Map особо не нужен.
Если же интересны подробности, то давайте начнем с основ.
С Elasticsearch сталкиваются многие. Но что происходит, когда хочешь с его помощью хранить логи «в особо крупном объёме»? Да ещё и безболезненно переживать отказ любого из нескольких дата-центров? Какой стоит делать архитектуру, и на какие подводные камни наткнёшься?
Мы в Одноклассниках решили при помощи elasticsearch решить вопрос лог-менеджмента, а теперь делимся с Хабром опытом: и про архитектуру, и про подводные камни.
Настройка сетевого взаимодействия сервисов не самая простая задача и часто осуществляется без глубокого понимания как требуется настраивать систему и какие настройки на что влияют. После миграции сервисов в docker контейнерах с centos 6 на centos 7 я столкнулся со странным поведением вебсервера: он пытался присоединиться к сервису по IPv6, а сервис же слушал только IPv4 адрес. Стандартный совет в такой ситуации — отключить поддержку IPv6. Но это не поможет в ряде случаев. Каких? В этой статье я задался целью собрать и детально объяснить как приложения resolve'ят адреса.
Всем привет!
Кратко о себе. По образованию я математик, а вот по профессии — программист. В сфере разработки с 2006 года. Хотя, поскольку программирование начали изучать ещё в школе, свои первые программки и игры я начал писать ещё в школе (примерно, с 2003). Так сложилось, что пришлось выучить и поработать на нескольких языках. Если не брать во внимание ВУЗ-овские лекции по С, С++, Бэйсику, Паскалю и Фортрану, то реально я работал с Delphi (более 6 лет), PHP (более 5 лет), Embedded (Atmel + PIC около 2.5 лет) и последним временем Python + чуть-чуть Scala. Конечно же без баз данных тоже никак не обойтись.
Для кого эта статья? Для всех, кто, как и я, хотел (или хочет) найти для себя достойную хорошо оплачиваемую работу с интересным проектом, классным коллективом и всякими плюшками. А также для тех, кто желает поднять свой уровень знаний и мастерства.
Меня зовут Сергей, мне 40 лет и сейчас я работаю Java разработчиком в немецкой компании. Мы занимаемся разработкой программного обеспечения для пивоварен оценки финансовых и кредитных рисков. Это моя первая работа в качестве разработчика. До этого я работал в сфере IT-поддержки и системной интеграции. Первого февраля 2019 г. закончился мой шестимесячный испытательный срок, и у меня на руках бессрочный контракт. Я хочу поделиться своим опытом, как можно самостоятельно выучить Java так, чтобы получить работу.
Это мой рабочий стол. Пить пиво в рабочее время у нас разрешено, мы же в Германии.
Моя первая статья: «IT-эмиграция с семьей. И особенности поиска работы в маленьком городе Германии, когда ты уже там»
