Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×
Тех. директор в UA2WEB
  • Як забезпечити безперебійну роботу під час відключення електроенергії — поради інженера-електрика

    у мене був випадок коли від маленької іскри при підключенні акумулятора він вибухнув, це просто для інфи, що може теоретично то так і є, як ви кажете, а практично буває дуже небезпечно

  • Rust, Clojure, Elixir та Objective-C. Українські розробники — про те, чому обрали непопулярні мови програмування

    Це не ідеальний інструмент для коротких скриптів і утиліт командного рядка

    В деяких ситуаціях допоможе nbb чи Babashka

    Підтримав: PKCLsoft
  • Про конференцію харківського ІТ-кластера щодо Дія.Сіті

    я вчора консультувався, мені кажуть що це не зовсім так, і потрібно щє доплатити 22% ЕСВ буде, з цього «доходу»

    Підтримав: Kostiantyn
  • Про конференцію харківського ІТ-кластера щодо Дія.Сіті

    ця інфа є неофіціоною, поки що. тобто, рівень довіри такий же, як і до іншої інфи з приводу неофіційного спілкування з представниками влади. у канві загальної інформаціі я вважаю що так воно і є, планують, але чи буде це чи ні, залежить і від нашої реакціі на Дія Сіті

  • Про конференцію харківського ІТ-кластера щодо Дія.Сіті

    Чтобы выйти из «аутсорс болота» (т е я так понимаю — торговли «сырой» рабочей силой, с минимумом добавочной стоимости) надо вначале бы разобраться с судами и соблюдением законности, чтобы возможно вообще было делать R&D и инновации, которые бы не украли сразу же. А в той де Дія Сіті заложен механизм, по которому фирма обязана предоставить всю информацию, в том числи и ту, что под NDA, проверяющим, если такового не предоставлено, исключение из рядов и «досчитывание» налогов по общей системе. Т е я в целом не против технопарков, но если уже делать технопарк, то делать так, чтобы в него хотелось идти, а не так, что в него запихивают насильно.

    Второе. Я — независимый контрактор. У меня несколько компаний, с которыми я работаю на протяжении уже десятка лет и более. По изложеной логике выходит я им должен сказать досвиданья, и искать себе новую работу, с заведомо более низкой оплатой труда локально? Да мне проще оставить всё как есть и уехать на ПМЖ куда нибудь в ближайшую страну типа Грузии/Эстонии/Польши и тп — туда, где готовы будут принять меня, с моими текущими контрактами и деньгами чем терять и снова искать работу с нуля в 40+.

    Підтримали: Alex, Oleksandr Viter
  • Про конференцію харківського ІТ-кластера щодо Дія.Сіті

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

  • «Демонтаж ФОП-моделі — це шок для ІТ-ринку України». Що думають IT-компанії про законопроєкт щодо посилення захисту працівників

    ФОП — це однозначно чорна схема

    По перше не «чорна», а «сіра», навіть стосовно найму.

    По друге, «сіра» ця схема не у всіх випадках... Я можу зрозуміти таку классіфікацию, коли це стосується взаімовідносин між украінською компанією та працівниками, але я не розумію кому заважає, коли ФОП консультує декілька компаній не в Украіні. Тобто, після заборони ФОП 3ю группи, я банально втрачу роботу і це мене непокоїть, особливо коли це називають «чорною схемою», не треба так підігрівати, це не чорна и не сіра схема, коли окрема людина працює як консультант.

  • Not Only SQL: ищем альтернативы реляционным базам

    Возможно автор и перегнул палку но в целом идея здравая: при наличии заведомо большого кол-ва однотипных товаров на складе считать каждую транзакцию по отдельности слишком накладно. Возможно гибридное решение о применении транзации должно принматься на соотношении остатков к кол-ву товара проданного в единицу времени.

  • Монитор для программирования

    зависит видимо от того, каким WM вы пользуетесь. дефолтные Mac, Linux/Unity и Windows не сильно хороши с несколькими мониторами. в конфигурации с тайлинг manager несколько мониторов дают больше плюсов

  • Повышение продуктивности

    Почитайте автора GTD David Allen новую книгу Ready for ANYTHING. Я делаю так — ставлю N интервалов на день, планирую чем в каждом интервале буду заниматьсья, и не отвлекаюсь в это время. В конце концов не отвлекаться заданное время не сложно.

  • Повышение продуктивности

    Только ставьте время 52 минуты для работы и 17 для перерыва. Сам пытался работать по 25, понял что не очень эффективно, часто пытался перерабатывать т к не хотелось прерываться. Теперь ясно, почему: lifehacker.com/...eal-productivi-1616541102

    Підтримав: Artem Zaika
  • Что из редактора делает IDE?

    Это если буквально переводить название. В реальности IDE это обычно что то монстрообразное, сознательно ограниченное в сфере применения под отдельный язык
    платформу, заточенное под конкретную цель.

    Підтримав: Dmytro Sirenko
  • Что из редактора делает IDE?

    На мой взгляд есть два основных отличия редактора и IDE. Первое, и главное состоит в том, что IDE пишется под конкретный язык или платформу. Т возьмём для примера один из лидеров рынка IDE — команию JetBrains. Исходя из концепции Язык=IDE они представили на рынок множество IDE, каждый для своей цели — PyCharm для Python, IntelliJ IDEA для Java, PHPStorm для PHP и так далее. Это свойство IDE является как хорошим, так и плохим т к по факту если у вас гибридный допустим проект где используется несколько языков, прийдётся или запускать несколько IDE или же ограничиться минимальным тем набором функционала подсветки и тп. Многофункциональные редакторы таким ограничением не обладают.

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

    На самом деле отличий немного, и часто обычный редактор может предоставить набор необходимых виджетов, потому в некоторых случаях границы стираются.

    Что выбрать? Зависит от многих факторов. Подход с IDE часто проще и понятнее, особенно для языков, в которых IDE является важным дополнением языка: C++, .NET, Java. Во вторых, из за простоты подхода IDE действительно по началу рекомендуется начинающим.

    Если же хочется полного удобства, управления, оптимизации среды то выбор один — выбрать себе редактор, который легко настраивается и обладает готовыми интеграциями с любым языком программирования. Я работаю в Emacs, чего и всем рекомендую. Альтернатива Emacs-VIM. Но минусы есть и в таком подходе — тут парадигма управления завязана на текст и управление с клавиатуры. Т е хочешь или не хочешь прийдётся понять какая клавиша что делает.

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

    Где то посредине между двумя крайностями находятся редакторы типа Sublime Text, с балансом фич, вижетов, и модулей расширения. Atom вообще не впечатлил, очень слаб во многих планах, но красиво выглядит eye-candy

  • За что увольняют программистов

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

    Не всегда в небольшой компании найдётся место человеку, который уже показал себя неспособным к сотрудничеству в коллективе. Когда большой пул программистов и проектов, тогда возможно место и найдётся... А в маленькой компании со временем всё таки остаются те люди, которые умеют найти общий язык.

    Підтримав: Voodymyr Samoilenko
  • За что увольняют программистов

    Тарас, я описал реальную ситуацию. Это на самом деле довольно типичная ситация когда программист интроверт, не в состоянии работать в коллективе. Иногда такие люди пишут хороший код, иногда не очень, это в общем то некритично. Главное тут то, что человек, которого я нанял должен быть готов к тому, что если проект пойдёт не на помойку, а реально начнёт приносить прибыль, то мы можем прийти к ситуации когда один человек этот проект не тянет. И на этом этапе уже становиться важным то, насколько человек адекватен и готов работать в коллективе. Часто он не готов. Как бы я не старался как менеджер оградить человека от моральной травмы общения с другими программистами, иногда самое гуманное что я могу сделать для него и для команды в целом — уволить (и конечно же, это не приносит мне удовольствия). Потому постарался дать такой совет — даже полных интровертов надо зараннее приучать к тому, что код не является их личной собственностью, а продукт взаимодействия команды. Иначе, в ряде случаев конфликта не избежать.

  • Mercurial vs. Git в коммерческой разработке

    Почему подпорка ответить просто — если уж мы девелопим фичу в ветке, то логично было бы делать выводы оттуда а не заставлять разраба писать в каждом коммите. Во первых надо сделить за дисциплиной, чтобы не забывали ставить, ну или как уже советовали сделать запрет на push изменений без подписей тасков. Мы так делали пока работали в svn, ну и сейчас это применяем в Jira + Git. Да, мою проблему этот подход решает, но называть его особенно удобным, имея рядом пример другой организации того же процесса я не могу.

  • Mercurial vs. Git в коммерческой разработке

    Хорошо, допустим после моих изменений для новой фичи X в ветке валится тест Y, как понять какое бизнес требование тест Y отслеживает? Я должен сформулировать проблему в терминологии: «При попытки реализации фичи X нарушается целостность исполнения бизнес требования Z, с привязанным тестом Y». Что делать далее? Как выяснить какую часть заложенной логике и какие бизнес требования поломались? Большая часть команд валят всё на отдел QA, пусть они сами разбираются. Мне же такой подход претит, он занимает в разы больше времени и не даёт качественного результата, т к метаданные могут отсутствовать (зависит от того, насколько хорошо организвана работа отдела QA). Я же просто избегаю лишних шагов, если есть ветка, могу сказу сказать о том, какое бизнес требование Z будет нарушено в связи с введением новой фичи X и далее инициировать дискуссию бизнес аналитики, QA и меня как разработчика.

  • Mercurial vs. Git в коммерческой разработке

    идея то простая — если мы *уже* пользуемся бранчами при создании новых фич, то в дальнейшем можно было бы положиться на эту информацию для раскрутки обратного процесса (см ниже). но суть простая — и польза следующая — допустим заказчик поручает сделать фичу X, программист открывает код, начинает менять, и находит кусок логики, включая unit test который повалится после введения новой логики, для фичи X. Вот тут внимание вопрос — к кому идти с вопросом, и как его сформулировать? я обычно формулирую просто — логика фичи X, противоречит логике фичи Y (нахожу бизнес требование к Y по коммиту, далее таску и связке). Без этой связки фича X конечно заработает, но разборки потом почему логика X поломало Y, Z ложится целиком на плечи QA. Я не привык ломать а потом разбираться, лучше вначале разобраться, и делать свои изменения осознанно, в рамках понимания проекта целиком а не логики отдельной фичи которая делается сейчас

    Підтримав: Александр Попов
  • Mercurial vs. Git в коммерческой разработке

    В статье уже это расписывал, но попытаюсь ещё раз. Как мы работаем — для каждой функционально отдельной фичи делается заглавный таск и своя ветка, привязанная к этому таску. Помимо «фича» веток есть ещё master, stable ветки, первая для интеграции, вторая — текущая версия на продакшн сервере. Далее, коммиты соответсвенно будут или в ветках, или напрямую в master/stable. Вопросы которые я хочу решать оперативно с точки зрения управления проектом — получить список всех изменений, сделанных по этой фиче. Второй вопрос который я могу задать, и хочу получить быстрый ответ — к разработке какой фичи относиться данная строка кода. Как я действую во втором случае — учитывая то, что фичи рождаются в ветках, моей задачей является найти ветку, и далее найти ассоциированый таск, таск может быть самодостаточным, может ссылаться на развёрнутые бизнес требования. Вот такая вот история. git branch —contains показывает с десяток бранчей, в которых находиться данный коммит, ведь с тех пор как коммит попадает в master, а от мастера делаются дальнейшие ветки. Возможно я как то неправильно это применяю? Меня интересует одна ветка, в которой данный коммит попал в код. Т е первая команда которую я запускаю (посредством своего ide конечно же, не буду сейчас на него указывать), получаю список строк кода, рядом коммит в котором последний раз менялась эта строка. Потом даю этот commit аргументом к git branch —contains и в общем случае получаю список всех локальных веток, в которые этот commit входит. Это малоинформативно и не является ответом на тот вопрос, на который я хотел найти ответ. Буду признатален если сможете рассказать как добиться нужного мне результата.

  • Mercurial vs. Git в коммерческой разработке

    Статья в ультимативной форме доказывет не то что hg лучше git (как раз технически наоборот), а что в конкретном бизнес процессе, с упором на traceability hg подходит лучше, по объективным причинам (их несколько, главная их которой конечно же ветки). На мой вопрос не ответили, отсыл к «куче книг, литературы» не засчитан т к это не решает мою проблему, поверьте, читал. Пусть люди сами переживают за себя, не переживайте так за них: они сами смогут сделать свои выводы. Всё на что Вы сослались это git-flow, который у нас применяется посредством Jira, но проблем указанных мною выше он не решает.

    Підтримав: Александр Попов
← Сtrl 123 Ctrl →