Все форматы удобны по-своему, но самый удобный для вас — это:
JSON
XML
HTTP
Protobuf
Другое
Очень странный вопрос, у них всех у есть несколько разных сфер приложения. Для конфигов есть текстовые JSON, YAML, XML, но никак не Protobuf, и тем более HTTP. Для запросов к API сейчас набирает популярность Protobuf, как альтернатива JSON over HTTP. Сам API тоже бывает очень разный — общедоступный или внутренний, для браузеров или для микросервисов, со схемой или без, и т.д. В document-oriented базах используются как эти, так и более специфичные форматы. Сериализация объектов в виде файлов — тоже популярный кейс.
Согласен, у меня мини-PC c Intel Core i3-7167U от XCY с пассивным охлаждением и в качестве домашнего сервера. Проц постоянно нагружен на 25%, хоть и греется, но терпимо.
Стоит упомняуть один очень качественно снятый мини-сериал на тему планируемой колонизации Марса, где дает комментарии сам Илон Маск. Он так и называется — "Марс".
Пишем ctor, и нажимаем tab два раза, получаем конструктор класса.
А с resharper — на один tab меньше.
Вообще, даже ctor полностью печатать не надо, его тоже tab-ом можно добить.
Когда-то я сделал для хабра перевод статьи "Почему BSD проиграла в битве с GNU/Linux?", где в том числе упоминался и Эрик Реймонд. Хочется верить, что когда-нибудь будет и пост "Почему Windows проиграла в битве с GNU/Linux?".
Купить Facebook было слишком дорого. Возможно, что наоборот: Facebook был вынужден купить Instagram и WhatsApp, тем самым три крупнейших в мире социальных графа оказались в одних руках. Аналогично с Mail.ru Group: VK, Одноклассники.
Такое ощущение, что спецслужбы США просто заставляют Майкрософт покупать сервисы, которые оперируют огромным объемом чувствительной информацией: hotmail, skype, linkedin, yammer, minecraft, aquantive, github, теперь tiktok.
Фундаментальное преимущество git — его распределенность: вся история есть локально, и можно полноценно работать даже когда нет сети, поэтому он такой быстрый. Сеть нужна всего в двух случаях: скачать новые коммиты с удаленного сервера (git fetch) [причем для всех веток сразу], отправить свои коммиты на удаленный сервер (git push).
С этой точки зрения команда git pull (с какими угодно опциями) — это "супер-команда", которая скачивает новые коммиты [также для всех веток сразу] и сразу же пытается автоматически интегрировать их с локальными коммитами на текущей ветке.
Для меня это две совершенно разные задачи. Отказ от этой "супер-команды" дает следующие преимущества:
Логическое разделение двух несвязанных операций.
Возможность увидеть и сравнить все изменения до их интеграции.
Возможность самому решать как делать интеграцию (--no-ff, --ff-only, standard rebase, rebase-via-merge, --squash).
Не запускать лишний раз скачивание коммитов с сервера. Именно поэтому git pull — всегда такая медленная операция, тогда как сами по себе merge и rebase быстрые, потому что им не нужна сеть.
Есть ясное понимание того, что происходит, без каких-либо сюрпризов. Не надо полагаться на какие-то опции этой "супер-команды".
Опция pull.ff only очень хороша, но не все про нее знают, и мало у кого она установлена. В моем конфиге она есть, но я в принципе не делаю git pull. Для таких случаев у меня есть алиас git fff, что значит fetch fast-forward, вот кусочек моего конфига:
[alias]
s = !git status -sb
f = !git fetch origin --tags --prune && git s
ff = !git merge @{u} --ff-only && git l1 && git s
fff = !git f && git ff
Категорически поддерживаю. Эта команда делает две совершенно разные вещи: fetch + merge, причем с непредсказуемым результатом, not the unix way. Очень жаль, что она есть, без нее было бы меньше магии и меньше путаницы.
В теории переделать исходники под macos проще, но все зависит от самого приложения. Лучше не мучаться и сразу запустить в докере или виртуалке.
Очень странный вопрос, у них всех у есть несколько разных сфер приложения. Для конфигов есть текстовые JSON, YAML, XML, но никак не Protobuf, и тем более HTTP. Для запросов к API сейчас набирает популярность Protobuf, как альтернатива JSON over HTTP. Сам API тоже бывает очень разный — общедоступный или внутренний, для браузеров или для микросервисов, со схемой или без, и т.д. В document-oriented базах используются как эти, так и более специфичные форматы. Сериализация объектов в виде файлов — тоже популярный кейс.
Согласен, у меня мини-PC c Intel Core i3-7167U от XCY с пассивным охлаждением и в качестве домашнего сервера. Проц постоянно нагружен на 25%, хоть и греется, но терпимо.
Стоит упомняуть один очень качественно снятый мини-сериал на тему планируемой колонизации Марса, где дает комментарии сам Илон Маск. Он так и называется — "Марс".
"Revolution OS" — захватывающая документальная лента про триумф идеологии open source.
Пишем ctor, и нажимаем tab два раза, получаем конструктор класса.
А с resharper — на один tab меньше.
Вообще, даже ctor полностью печатать не надо, его тоже tab-ом можно добить.
Когда-то я сделал для хабра перевод статьи "Почему BSD проиграла в битве с GNU/Linux?", где в том числе упоминался и Эрик Реймонд. Хочется верить, что когда-нибудь будет и пост "Почему Windows проиграла в битве с GNU/Linux?".
TypeScript и Blazor/C# — слишком разные технологии, поэтому их сложно назвать конкурентами. Оба инструмента будут и дальше развиваться в своих нишах.
Где-то читал, что у шизоидов часто корявый почерк.
Кроме конфига, автора можно указать непосредственно в команде
И еще один способ — через переменные
Когда лень писать юнит-тесты.
Купить Facebook было слишком дорого. Возможно, что наоборот: Facebook был вынужден купить Instagram и WhatsApp, тем самым три крупнейших в мире социальных графа оказались в одних руках. Аналогично с Mail.ru Group: VK, Одноклассники.
Такое ощущение, что спецслужбы США просто заставляют Майкрософт покупать сервисы, которые оперируют огромным объемом чувствительной информацией: hotmail, skype, linkedin, yammer, minecraft, aquantive, github, теперь tiktok.
Отвечу более развернуто.
Фундаментальное преимущество git — его распределенность: вся история есть локально, и можно полноценно работать даже когда нет сети, поэтому он такой быстрый. Сеть нужна всего в двух случаях: скачать новые коммиты с удаленного сервера (git fetch) [причем для всех веток сразу], отправить свои коммиты на удаленный сервер (git push).
С этой точки зрения команда git pull (с какими угодно опциями) — это "супер-команда", которая скачивает новые коммиты [также для всех веток сразу] и сразу же пытается автоматически интегрировать их с локальными коммитами на текущей ветке.
Для меня это две совершенно разные задачи. Отказ от этой "супер-команды" дает следующие преимущества:
Опция
pull.ff onlyочень хороша, но не все про нее знают, и мало у кого она установлена. В моем конфиге она есть, но я в принципе не делаю git pull. Для таких случаев у меня есть алиасgit fff, что значит fetch fast-forward, вот кусочек моего конфига:Категорически поддерживаю. Эта команда делает две совершенно разные вещи: fetch + merge, причем с непредсказуемым результатом, not the unix way. Очень жаль, что она есть, без нее было бы меньше магии и меньше путаницы.
Советую вместо git pull делать примерно так:
И после этого уже merge или rebase.
Я вспомнил, что целую оду Nim написал один интересный человек, который, кстати, оставил эпичные комментарии к одной статье.
WAMP стек? В чем преимущество?
Есть такая интересная штука — standup bot. Кто-нибудь пробовал?
В личном кабинете my.egov.kz можно только увидеть свой адрес и дату прописки. Но справку в виде pdf получить нельзя.