• Сколько зарабатывают ИТ-шники в Германии
    0

    Образ жизни "особо не транжирить, но и не задумываться о тратах". Аренда двухкомнатной квартиры, редко готовить дома, ничего особенного. С учётом разных непредвиденных расходов, легко набиралось 2000 в среднем при чистой зарплате в 2300.


    А на такси в Берлине можно ездить только миллионерам ИМХО :)

  • Сколько зарабатывают ИТ-шники в Германии
    +1

    Начинал работать в Берлине с 45к (миддл, C++/D). Если специально не экономить, то этого впритык хватало, чтобы жить одному под ноль. На 60к стало уже нормально, но ощущения "высокооплачиваемого специалиста" и близко нет. Потом договорился на удалённую работу с теми же условиями и вернулся обратно в Ригу — и всё стало совсем иначе :)


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

  • Сколько зарабатывают ИТ-шники в Германии
    0

    (промазал)

  • Указатели в C абстрактнее, чем может показаться
    0

    Все дело в формулировке "следующего сразу за первым в том же адресном пространстве".


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

  • Указатели в C абстрактнее, чем может показаться
    +1

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

  • Указатели в C абстрактнее, чем может показаться
    0

    Вообще-то приведенная в статье цитата из 6.5.8 говорит об этом прямым текстом — "Во всех остальных случаях поведение не определено" (после списка валидных сравнений).

  • Указатели в C абстрактнее, чем может показаться
    +1

    Потому что указатели не обязательно имеют численное представление, для которого арифметические операции имеют смысл. Представим себе такую архитектуру, где объекты разного типа имеют независимую систему адресации и может быть бесконечное количество указателей со значением "42", которые не равны друг другу (т.к. указывают на данные разных типов). Это вполне легально по стандарту С.

  • Google оштрафован на рекордные $5 млрд за нарушение антимонопольного законодательства в Европе
    0

    Отличная новость, экономическая ситуация в глобальной IT отрасли явно нездоровая и хорошо, что этому уделяют всё больше внимания.

  • Google оштрафован на рекордные $5 млрд за нарушение антимонопольного законодательства в Европе
    +1

    Антимонопольные структуры существуют в большинстве (всех?) капиталистических странах не просто так. Монополия естественным образом следует из неконтролируемой рыночной конкуренции и впоследствии уничтожает её же, потому любой свободный рынок должен быть немного несвободен, чтобы выжить.

  • Вредный Кейворд «Interface»
    +3
    Народ, если у вас есть мнение, то, пожалуйста, выразите его словами.

    Человек, для которого ООП сводится к наследованию ("Не пользуйтесь ООП в ООП") — настолько далёк от понимания предмета, что нет смысла даже тратить время на объяснения — просто ставишь минус и идёшь дальше.

  • Чего из Rust мне не хватает в C
    0

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


    Но про ассемблер неверно, так все такие языки позволяют писать платформозависимый код. В том же Rust inline assembly планируется как часть языка (емнип уже есть в nightly, но не stable сборках). В С на практике тоже, хотя это и не часть стандарта.


    Для меня сейчас понятие "уровня" полностью сводится к наличию/отсутствию обязательного рантайма и возможности unsafe работы с памятью.

  • Чего из Rust мне не хватает в C
    +3

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

  • Team Leader. Быть или не быть, вот в чем вопрос
    0
    какие

    1) Быть контактным лицом, если кому-то что-то нужно от этой команды
    2) Раз в неделю собираться на митинг тим лидов и озвучивать там важные для команды темы (и потом транслировать обратно результат)


    почему у них

    Потому что кому-то надо это делать :) Существенного влияния на зарплату это не оказывает.


    у них есть метрики привязанные к зарплате

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

  • Team Leader. Быть или не быть, вот в чем вопрос
    0
    почему Вы считаете что группа Senior-разработчиков в команде не может выполнять задачи

    Например, потому что я так не считаю :) Более того, в компании, где я работаю, вообще нет никакого строгого деления на ранги и никакого технического менеджмента, одни лишь только Software Engineer. При этом тим лиды есть, но они все — обычные разработчики, просто с дополнительными обязанностями. Впрочем, когда компания была меньше, не было даже их, и было ещё лучше.


    Просто нужно нанимать людей, умеющих принимать решения самостоятельно — и изначально объяснять, что таких решений от них ждут.

  • Team Leader. Быть или не быть, вот в чем вопрос
    +1

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


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


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

  • Как захватить/защитить open-source проект
    +1
    Не внутреннюю, а публичную репу клона, просто там будут не все исходники. Да, разоряется, т.к. на консалтинге и двойном лицензировании мертвого форка денег не поднимешь.

    Это довольно узкое видение причин, по которым компании могут выкладывать код в публичный доступ. Я куда чаще встречаюсь с ситуацией, когда выкладываются полезные, но непринципиальные для бизнеса библиотеки и их дальнейшие форки никого не волнуют. Основная цель в таком случае — PR, а вовсе не получение патчей.


    Ключевой для бизнеса код выкладывается очень редко, вне зависимости от лицензии.

  • Как захватить/защитить open-source проект
    +1
    Насколько я помню, GPL — это борьба «копилефта» с «копирайтом» оружием последнего.

    Да, это хороший вариант описать ситуацию вкратце. Ещё GPL очень удобен в контексте двойного лицензирования. Это вообще очень хорошая лицензия и у меня к ней нет никаких претензий.


    К чему у меня есть очень много претензий, так это к столлмановскому двоемыслию, в котором подобная ситуация подаётся не просто как "свобода", но даже как "настоящая свобода" (в противовес "ненастоящей" BSD).


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

  • Как захватить/защитить open-source проект
    +1

    Конечно вправе. Но не нужно при этом использовать лицемерные метафоры вроде "Это как называть замок в моей машине «ограничением», потому что он останавливает остальных от присвоения моей машины".

  • Как захватить/защитить open-source проект
    +2

    Что общего между копирайт лобби и поклонниками GPL? И те, и те считают, что создание точной копии информации без потери оригинала — воровство. Хотя существует достаточно количество людей, которые используют BSD-like не только осознавая полную потерю контроля, но и ставя это своей непосредственной целью.

  • Большие бинари в моем Rust?
    +3

    Есть ещё несколько плюсов:


    1) более эффективная работа с процессорным кэшем инструкций при переключении между разными процессами использующими одну и ту же библиотеку
    2) меньше размер пакета для развёртывания на сервере (полезно в основном владельцам бюджетных VPS с лимитами на upload)
    3) централизованное получение security обновлений если авторы библиотеки серьёзно относятся к версионирования ABI


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

  • Большие бинари в моем Rust?
    +2

    Чтобы не было голословного обмена утверждениями, вот данные по актуальным компиляторам на x86_64 Arch Linux (-O -inline + strip):


    -rwxr-xr-x 1 dicebot dicebot  12K Jul 11 16:44 ./hello-dmd-shared
    -rwxr-xr-x 1 dicebot dicebot 558K Jul 11 16:43 ./hello-dmd-static
    -rwxr-xr-x 1 dicebot dicebot 1.8M Jul 11 16:44 ./hello-gdc-static
    -rwxr-xr-x 1 dicebot dicebot  12K Jul 11 16:44 ./hello-ldc-shared

    (ldc-static и gdc-shared под рукой не было, но общая картина должна быть очевидна)

  • Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket
    0
    И вот именно для того, чтобы облегчить слияние такого рода (`fetch pr-branch` + `rebase upstream/base` + `push upstream/base HEAD`) и была написана утилита, про которую я упоминул изначально. Чтобы можно было просто сделать `git hub pull rebase ID` и получить желаемую историю.
  • Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket
    0
    Это недостаточная связность на мой взгляд. Тут две проблемы:

    1) Требование создавать по отдельному pull request на каждый баг фикс сильно отяжеляет разработку бюрократией (коммиты напрямую в основные ветки строго запрещены)

    2) Типичное для ревью требование отделять коммиты с форматированием от коммитов с семантикой очень полезно и впоследствии при git bisect. Это касается и реализации больших фич — грустно было бы обнаружить, что проблема возникла из-за одного цельного коммита на +5000 -5000.

    У сохранении истории коммитов есть, впрочем, свои недостатки. Главные — нужно настраивать CI для тестирования всех коммитов, а не только HEAD; не удобного способа проследить связь между коммитом и pull request. В планах попытаться решить последнюю проблему через https://git-scm.com/docs/git-notes
  • Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket
    0
    Отнюдь, у нас семантическое разбиение по коммитам (и читабельность их названий) является частью code review. Проблема с squash в том, что так в один коммит попадает множество не связанных между собой изменений, которые должны в истории храниться отдельно.
  • Rebase Flow. Способ приготовления и его поддержка в GitHub, GitLab, BitBucket
    0
    Тоже используем rebase модель, но без обязательного squash (чтобы история была читабельнее). Написали для этого свою консольную утилиту для работы с GH: https://github.com/sociomantic-tsunami/git-hub
  • man!(D => Rust).basics
    0
    Самое забавное тут то, что после изучения Rust отношение к D несколько изменилось — в плане лаконичности и выразительности последний сильно выигрывает. Впрочем, «явность» Rust-сообщество наоборот считает преимуществом. По моим ощущениям, в Rust чаще руководствуются «академической правильностью», а в D более практичный подход.

    У меня после продолжительных экспериментов с Rust осталось очень похожее впечатление. Его строгость очень привлекает в больших проектах с критической важностью корректности, но затраты времени на написание простых вещей очень уж непрактичны. Вероятнее всего, даже если я решу начинать какой-либо новый проект на Rust, прототип всё равно будет написан на D.
  • man!( Go => D ).concurrency
    0
    Всё интересует, может серию статей?

    Очень неохота, такие статьи надо утверждать в отделе маркетинга и вообще возни много. Лучше подождите месяц и послушайте http://dconf.org/2016/talks/lucarella.html и http://dconf.org/2016/talks/panel2.html
  • man!( Go => D ).concurrency
    +1
    Я себе на vibe.d бложик написал, считается? :)
  • man!( Go => D ).concurrency
    0
    Многовато придётся рассказывать :) Don довольно много упоминает в http://dconf.org/2014/talks/clugston.html
    Что-то конкретное интересует?
  • man!( Go => D ).concurrency
    0
    Я для этого читал исходники :) Хотя наверняка должна быть литература по старым операционными системам (до появления многозадачности), которые использовали как раз cooperative multitasking. Fiber это всего лишь аналогичная концепция применённая в рамках одного процесса.
  • man!( Go => D ).concurrency
    +2
    Согласен с тем, что в этом есть доля писькомерства, но все таки большое количество разнообразных популярных проектов для языка, который появился не так давно — показатель его практичности

    Это очень популярное заблуждение. Практичность и вообще технологические достоинства языка имеют сравнительно малое влияние на популярность (если только он не откровенно ужасен). Решает громкое имя, агрессивный маркетинг, удачные пилотные проекты и в целом snowball effect. Комментарии в этом треде ("мало библиотек, должно быть с языком что-то не так") это только лишний раз подтверждают.
    Программисты тоже люди :)
  • man!( Go => D ).concurrency
    0
    Ну, вот, например: www.sociomantic.com

    Мы используем не vibe.d, а схожую по архитектуре, но самописную систему.
  • man!( Go => D ).concurrency
    0
    "иллюзию параллельности", пардон.
  • man!( Go => D ).concurrency
    0
    https://en.wikipedia.org/wiki/Cooperative_multitasking
    Реализация на практике чаще всего сводится к выделению памяти для стека и регистров и коду, который переключает регистры на другой контектст. Существенное отличие от threads в том, что операционная система про них ничего не знает и контекст переключается только когда где-то в коде программы явно вызывается функция вида Fiber.yield().
    Эффективность тут даже не столько в скорости переключения контекста (хотя экономить на syscalls всегда важно), сколько в количестве переключений. Равномерное распределение процессорного времени на тысячи потоков может стать причиной того, что программа проводит все время в переключениях и не выполняет полезной работы. В случае с yield, контектст будет переключен только когда программа сама посчитает это нужным.
    Что будет если файбер повис. Поток тоже повиснет?

    Да, поэтому системы основанные на fiber практически всегда используются в сочетании с async I/O
    Как вообще очередь устроена

    По разному. Концепция fiber это базовый системный примитив, который умеет только переключать контексты и больше ничего. Различные библиотеки могут реализовывать разную логику очередей на основе этого примитива. В случае с D, Fiber является частью стандартной библиотеки. А вот конкретная очередь, о которой идёт речь в статье, уже реализована в сторонней библиотеке vibe.d и основана на event loop (например, libevent).
    Обычно такая библиотека также определяет абстракцию Task (например http://vibed.org/api/vibe.core.task/Task) которая использует Fiber для реализации, но также определяет такие вещи как модель передачи данных между контекстами. В некотором роде goroutine — это task в стандартном go runtime scheduler.
  • man!( Go => D ).concurrency
    0
    волокна D выполняются параллельно, в Go — конкурентно

    Это неверное утверждение. В обоих языках происходит параллельное выполнение worker threads внутри которых происходит конкурентное выполнение fibers. Волокна вообще не могу выполняться параллельно сами по себе, по их определению. Разница на таком низком уровне только в том, что планировщик Go может переместить уже выполняемый fiber в другой worker thread (что создаёт иллюзию конкурентности и между goroutine), а в vibe.d соответствие неизменно.
  • man!( Go => D ).concurrency
    0
    Но такой планировщик реализован в проекте vibe.d

    Формулировка немного вводит в заблуждение — планировщик vibe.d не перемещает task/fiber между потоками. После того, как worker thread был выбран, конкретный task будет выполняться именно в нём до самого завершения. Причём это не дефект реализации, а осознанное решение, т.к. перемещение между потоками очень недружелюбно к оптимизации и кэшированию, а удобство, по большей части, мнимое.
  • man!( C => D )
    +3
    Этот код не скомпилируется:

    double.min
    


    Для числел с плавающей точкой требуется использовать свойство .min_normal — это сделано во избежание недопониманий о том, что это не является минимумом в том же смысле, что и у целых чисел.
  • WebAssembly: начало новой эры
    +1
    Мечтаю о временах, когда можно будет заниматься веб-разработкой совсем без JavaScript
    WebAssembly выглядит хорошим шагом в этом направлении
  • Управление и уборка в D
    0
    Это API и реализация базового набора аллокаторов + инструментов для их композиции. Предназначены они не столько для настройки выделения памяти в библиотеках (как, например, STL allocators), сколько для реализации эффективных стратегий работы с памятью в пользовательских приложения.

    Библиотеки (в идеале) должны вместо этого использовать range-based API и ленивые вычисления, чтобы откладывать принятие решений о способе аллокации как можно дольше.

    Рассматривается вариант настраиваемых глобальных аллокаторов для new / delete, но я практически уверен, что это никогда не будет работать надёжно «из коробки».
  • Управление и уборка в D