• Есть ли что-то в PhpStorm такого, чего нет в VSC, что-то такое принципиально нужное, чтобы стоило рассмотреть как альтернативу?

    delphinpro
    @delphinpro Куратор тега PhpStorm
    frontend developer
    VS Code неплохой редактор. А если обвесить плагинами, то возможности приблизятся к полноценной IDE.
    PhpStorm – полноценная IDE что называется "из коробки". Установил и у тебя все есть сразу и работает.

    Поэтому вопрос знатокам - стоит ли плотно тестить шило, если уже есть нормальное мыло?))


    На мой взгляд – стоит. Но пары дней будет мало. Нужно неделю-две посидеть, освоиться. И потом не слезешь.
    Ответ написан
    9 комментариев
  • Как выдать удостоверяющие сертификаты в локальной сети для внутренних сервисов в IIS (не self-signed)?

    athacker
    @athacker
    Все сертификаты рутовых УЦ -- самоподписанные. Сюрприз, да? :-) Если на пальцах, то доверие основывается на том, что "ну, это самоподписанный сертификат, но это же уважаемая контора...". Поэтому в ОС и в некоторых браузерах (Firefox, он своим хранилищем пользуется. Хром или IE -- пользуют системные, на винде, по крайней мере) есть хранилище корневых сертификатов удостоверяющих центров, которые (сертификаты) являются доверенными.

    Есть удостоверяющие центры, сертификаты которых подписаны другими удостоверяющими центрами. Но на самом верху цепочки доверия -- всё равно самоподписанные серты.

    Вам нужен свой PKI, это факт. Если нет желания/возможности делать УЦ на базе Microsoft Certification services, возьмите пакет easyrsa, подписывайте сертификаты им.

    По фэншую схема делается так -- создаётся корпоративный root CA (корневой удостоверяющий центр), с самоподписанным сертификатом, на каком-нибудь, например, ноутбуке старом. Потом генерируется ещё один ключ -- для подчинённого УЦ (sub-CA). Этот ключ подписывается сертом вашего root CA (с ноутбука), после чего ноутбук выключается и прячется в сейф. А вот уже с сертом sub-CA вы подписываете все серты для ваших серверов и сервисов. Ключи и CSR должны генерироваться только на тех хостах, где они и будут использоваться. Это если по фэншую. Но если вам просто важен замочек в строке адреса и отсутствие ругани, можно обойтись одним root CA, без sub-CA, а генерить ключи можно тем же самым easy-rsa, перенося потом ключ и серт на необходимые вам сервера с IIS.

    Сертификаты вашего root CA и sub-CA нужно будет установить в хранилища всех ваших десктопных компов, серверов и т. п. А также в хранилища браузеров, если у вас используются браузеры, которые не смотрят в системные хранилища. Это легко делается доменной политикой, но ввиду отсутствия у вас домена -- можно и скриптануть. Использовать certutil, например (если речь про винду, опять-таки).

    А IIS у вас там, Apache или nginx, или другие сервисы, которые умеют в TLS -- это дело десятое, от этого схема генерации и выдачи сертификатов не меняется.
    Ответ написан
    2 комментария
  • Какую литературу можно найти по golang?

    @programrails
    Я бы рекомендовал изучение в такой последовательности:

    Beginner level (синтаксис языка):

    1. Начать с golang-book.ru . Это на русском и довольно неплохо для начинающего.

    2. https://golang.org/doc/effective_go.html - это уже на английском, но всё равно толково и хорошо заходит после 1-го пункта. Кратко, по делу, без воды, достаточно понятно.

    После прочтения этих 2 пунктов у Вас уже будут базовые понятия о языке.

    Intermediate level (concurrency - многопоточность):

    Как ни пытался, не смог определить какую-то конкретную универсальную книгу. На этом уровне много плохих книг, сложно выделить что-то хорошее. Относительно неплохими для этого уровня (пока что) показались:

    (продолжаем последовательность изучения Go по пунктам):

    3. Базовый веб сервер на Go Статья, без которой дальнейшее трудно заходит (книгоавторам всем дружно лень такое нормально объяснить).

    4. M. Curtis - Level Up Your Web Apps With Go
    Читал - и не понимал - что происходит? Чувак явно пишет рельсы на Go! Всё такое до боли знакомое... Что такое? А потом смотрю в профиле https://www.linkedin.com/in/mal-curtis/ - так он же пишет на работе на Ruby on Rails! Так что книжка отлично зайдёт рельсовикам, осваивающим Go. Книга неплохая, автор явно старался. Автор, ты хороший человек.

    5. K. Cox-Buday - Concurrency in Go. Tools and Techniques for Developers. Книга не очень удачная, но пока я не успел найти что-то получше. Автор - женщина, и глупая. Книга читается мучительно и крайне медленно. Охват материала неплох - но объяснения косноязычные, с водопадом лишних слов и эмоций, примеры кода неоправданно переусложнены, ряд тем вообще остались бы непонятыми, если бы не гугление. Читаю и матерюсь на каждом шагу.
    PS Последние 2 главы пошёл уже такой горячечный бред, что я просто не смог заставить себя читать этот ужас. Бросил. В общем, далее параграфа Queuing читать не стоит. Книга прекрасно иллюстрирует тезис, что, какими бы умными ни были женщины, они всё равно дуры, и нечего им в программировании делать (кроме разве что 1С).
    К сожалению, книгу прочесть всё-таки надо, ибо охват хорош - а заменить книгу особо нечем (в смысле другой книгой, продаваемой за деньги - разве что статьями).

    Есть ещё книга N. Kozyra - Mastering Concurrency in Go - но у неё ужасные отзывы - да и я пытался читать другую книгу по Go у этого же автора - и мне также крайне не понравилось.
    Смешно сказать - но по Go нет ни одной путёвой книги про Concurrency (единственное, ради чего Go был создан)!

    6. Лучшее объяснение Go Context, что я пока видел. Оно даже лучше официального (написанного индусом, и оттого плохого).

    7. M. Tsoukalos - Mastering Go - но только Chapter 10: Concurrency in Go – Advanced Topics - и исключая параграф Worker pools (он ошибочный - там ничто не сдерживает размножение горутин - какой же тогда это пул).
    Средне-удовлетворительная глава, звёзд с небес не хватает, интереснее всего был параграф Sharing memory using goroutines - частный пример Катькиного Confinement'а.

    Advanced level (микросервисы на Go):

    Я пытался читать N. Jackson - Building Microservices with Go - это оказалось невозможным, книгу написал какой-то сумасшедший безумец, находящийся в состоянии наркотического опьянения. Отзывы на Амазоне это подтверждают.

    Также я попытался читать M. Ryer - Go Programming Blueprints (2 ed) - только главу Chapter 10: Micro-services in Go with the Go kit Framework - не понравилось. Примеры кода сложноваты (автор пытается построить реальную систему - ну и дурак - вместо того, чтобы ограничиться демо-примером), объяснения сопутствующего материала никакие (по сути, их нет). Бесполезная глава. Несколько тем свалены вместе - но ни одна толком не объяснена. Очень слабенький автор.

    Вердикт: нормальной книжки по теме "Go микросервисы" пока не обнаружено. Придётся изучать эту тематику из статей и инструкций по использованию микросервисных Go-фрэймворков - вот списочек фрэймворков:


    Я начал с gRPC. Сначала прочёл официальную доку по protobuf (включая раздел о Go). Дока оказалась достаточно вменяемой. Но зато официальная дока по gRPC уже оказалась совершенно паршивой. Там 2 примера - попроще и посложней. Писали доку явно последователи тех, кто писал доку к первому ангуляру (т.е. те, кому я бы отрубил обе руки по самые плечи). Понять что-либо без исходников (к статье) - нереально. Но - исходники ещё надо найти, ибо в статье ссылки на них ... нет. Оказалось, исходники тут: https://github.com/grpc/grpc-go/tree/master/exampl... . Но даже с ними - всё довольно непросто понять - даже в простейшем примере. Потому что авторы умолчали о многих важных моментах. Т.к. им в падлу шевельнуть задницей лишний раз. В общем, есть нужда в нормальном авторе, кто опишет, что такое gRPC. Попробуйте почитать статью от Шизы - это слегка окультуренный сокращённый пересказ сложного случая.

    Рассмотрим Go Micro. Продукция очередного кретина (да ещё и спорного качества). Что, скажите, можно понять из таких "объяснений"? Кстати, ищите в Яндексе термин "Service Discovery" - здесь нужно понимать, что это. Посмотрите и Consul. Вот ещё разумная статья о Go-микросервисах. И ещё я понял - без предварительного изучения protobuf и gRPC понять Go Micro будет затруднительно (если вообще возможно). Желаю вам никогда не встретить на работе продукцию этого дегенерата. Go Micro показался мне китайским фонариком со встроенными компасом, радиоприёмником, часами, зарядкой, отвёрткой, точилкой для карандашей, ногтерезкой, и т.д.

    Идём дальше. Go kit производит намного более лучшее впечатление. Правда, документация не полная - автору не хватило терпения её закончить. Но всё же разобраться можно - есть исходники-примеры, снабжённые подробными комментариями. Автор мне понравился.

    Почитайте полезную статью-сравнение.

    Приложение:

    Гоняться за русскоязычными книгами по Golang не рекомендую. Я прочёл на русском:
    - А. Донован, Б. Керниган - Язык программирования Go
    Это совершенно отвратительная бездарная книга.
    и просмотрел оглавление русскоязычной книги:
    - М. Саммерфильд - Программирование на языке Go
    Хотя я её не читал, но беглый просмотр её оглавления создаёт самое негативное впечатление о книге. Такое ощущение, что это целенаправленная диверсия против изучающего golang, с целью развести его на время (прочтения) и деньги (при покупке). Марк Саммерфилд - это профессиональный графоман, посмотрите сами на его карьерный путь: https://www.linkedin.com/in/qtrac/

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

    М. Батчер, М. Фарина - Go на практике - на русском языке - эта книга вроде бы достаточно неплохая, но она для опытного разработчика - и она не излагает системно - а отрывисто.

    Пытаться читать спецификацию языка также не рекомендую - ничего не поймёте:
    https://golang.org/ref/spec

    Заключение

    Нормальной литературы по Go практически нет (кроме азов). Все микросервисные Go-фрэймворки плохо документированы, вынуждая разбираться в них по примерам с исходниками (!).

    Англоязычных книг по Golang в электронном виде бесплатно - много, более 30 (а то и под 50). Многие написаны индусами, или оторванными от жизни вузовскими преподами, или какими-то левыми любителями Go (у таких "книг" даже нет ISBN). Есть даже книги, написанные неграми! Все такие книги требуют осторожного выбора. Почему именно Go вызвал у окружающих непреодолимые позывы к графоманству? Такое впечатление, что многие авантюристы решили "срубить баблишка" на "хайповой" теме. Действительно, найти хотя бы нормальную книгу (не говоря уже о хорошей) - оказывается по факту крайне непросто - почему-то именно к Go примазались многочисленные негодяи и бездари - как ни в каком ином языке программирования.

    Всё, о чём я рассказал в этом посте, доступно бесплатно онлайн в электронном виде (Либген, к примеру).

    В общем-то, основное внимание при изучении Go следует уделить его возможностям по многопоточности (concurrency), которые включают низкоуровневые механизмы (как в C++) типа мьютекса и высокоуровневые механизмы типа каналов. Собственно, это как раз то самое, зачем Go вообще понадобился. Вторая по значимости тема в Go, как мне кажется, это микросервисы.
    Ответ написан
    Комментировать
  • RAID: Аппаратный vs Программный?

    RicoX
    @RicoX
    Ушел на http://ru.stackoverflow.com/
    Плюсы программного: большая гибкость настроек, например, можно часть данных с диска держать в рейде часть нет, или в разных рейдах разные части, можно удобно переносить с сервера на сервер, легко расширять, легко мониторить.
    Минусы программного: ниже производительность, выше сложность настройки, нет BBU.
    Плюсы аппаратного: Выше скорость, ОС не видит что это рейд и работает с единым диском, не нужна поддержка рейда средствами системы, не чувствителен к резкой потери питания благодаря BBU, поддерживают разные интересные фишки типа CacheCade
    Минусы аппаратного: хуже гибкость, нужно иметь всегда в запасе еще один рейд контроллер на случай выхода из строя основного, цена.
    Плюсы вашего варианта: уже есть и работает, ничего делать не нужно.
    Минусы: Собрал минусы из обоих подходов и нет ни одного плюса, программный костыль средствами биоса, восстанавливать хреново, от сбоев не застрахован, гибкости нет, BBU нет, не рейд, а одно название.
    Ответ написан
  • Удаленная работа фултайм для джуниора, правда или вымысел?

    webirus
    @webirus
    Тыжверстальщик! Наверстай мне упущенное...
    Удаленная работа для джуна - не вымысел, вполне себе реальность.
    Но учтите сразу, что у вас не будет (или будет небольшой) профессионального роста.
    Работая в команде, вы моглши бы решать сложные задачи быстро.
    Удаленно, вы будете тратить время, больше работать.
    Это обычная практика. Исключение если вы вундеркинд.
    Поэтому серьезные работодатели не сильно доверяют джуниорам на удаленке.
    Да и просто совет - работайте в офисе, набирайтесь ума.
    Если компания не дает вам профессионального роста, смените на более топовую.
    Ответ написан
    5 комментариев
  • Vpn между главный офисом и дочерними структурами?

    @azazelpw
    Linux SA
    1. Дешево и стабильно.
    Mikrotik 951 + OpenVPN, подключение звездой.
    Плюсы есть thedude для постройки интерактивной карты сети и управления каждым коммутатором.
    Можно написать скрипт переключения провайдеров или ЛоадБаланс сделать.
    Минус, прозрачный прокси сервер для логирования подключений нужно ставить отдельно.
    2. Средний уровень.
    LinuxRouter(iptables+route)+OpenVPN
    Плюсы, большой функционал для тестирования и диагностики соединений,
    Можно поставить прозрачный прокси и кучу других наворотов, в будущем на нем можно развернуть asterisk для SIP телефонии и связать транками между собой филиалы. Чем сэкономить кучу денег компании. Так как виртуальные АТС это абонентка.
    Можно поставить Zabbix для диагностики всех компьютеров в дочерних структурах.
    Можно настроить переключение каналов и балансировку каналов.
    Минусы. Сложно в освоении, придется поднять жопу с дивана и начать техническую литературу. Возможности безграничны.
    Решение не из коробки и его придется проектировать, в идеале должен быть НОРМАЛЬНЫЙ гуру по линухам и сетям.
    Единый центр управления надо будет писать самому, но на старте можно использовать Ajenti.
    3. Дорого и глупо.
    Заказать реализацию у Интегратора. А он уже может напихать Цисок и прочей херни, которая не нужна для прокачки трафика.
    Ответ написан
    7 комментариев
  • SSD OSZ Vector. Скорость чтения меньше, чем скорость записи. Как так?

    Jump
    @Jump Куратор тега Твердотельные накопители
    Системный администратор со стажем.
    Ну судя на картинке скорость чтения все таки больше чем скорость записи...
    Судя по практически одинаковым скоростям чтения и записи в районе 250МБ/с я думаю у вас sata2.
    А по поводу TRIM - на скорость чтения он никак не влияет.
    Ответ написан
    Комментировать
  • Backuppc очень быстро забивает диск. Кто сталкивался, как починить?

    alexclear
    @alexclear
    A cat
    apt-get install ncdu
    ncdu -x /DISK/backups


    Вам поможет
    Вместо apt-get подставьте свой пакетный менеджер
    Ответ написан
    Комментировать