Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть
  • Почему я против тестов на собеседованиях для IT-специалистов. Взгляд рекрутера

    Чи може те що заважає HR-у закрити позицію — буди добрим для HR-а)))

  • Топик для поиска работы

    Привіт!

    Буду радий запросити до розробки MVP HW стратапу із США:
    — розробника AWS (IoT, Cognito, ElastiCache, Lambda, SNS, Kinesis)
    — розробника iOS (Apple SDK або iOS+Android by Qt)

    atlascoder@gmail.com

  • Понять интерфейсы

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

    Але якщо дивитись на програму не на як написав и забув, а як на щось, що буде багато разів змінюватися (а воно буде!!), то стає зрозуміло, що зміни робити краще, якщо частини системи легко и зрозуміло відокремлюються від всього іншого. З інтерфейсу легко щрозуміти як саме частини системи пов‘язані та взаємодіють. І тоді легше та безпечніше змінювати систему, та взагалі ії розуміти.

    В цьому аспекті стає зрозуміло, нащо взагалі ООП, інтерфейси, IoC, DI, solid, etc...

  • Топик для поиска работы

    Привіт!

    Шукаю джуна чи мідла для Embedded проектів. FreeRTOS, C/C++, далі можливо Linux Embedded.
    Проекти — hardware продукти в секторі IoT.

    Якщо цікаво — пишіть на atlascoder@gmail.com

  • Путівник галактикою Ruby

    Також, одна із крутих фич Рубі — це інтерактивний інтерпретатор IRB

  • Путівник галактикою Ruby

    Так, Ruby класний, але, якнамене, є один такий-собі мінус, що навряд робить його легким для початківців. Цей мінус пов’язани із впливом 3 факторів в комплексі: і) динамічна типизація, іі) відсутність безкоштовного якісного IDE, ііі) DRY вимагає розуміння ООП та специфіки Ruby.

    На практиці, динамічна типизація не дозволяє перевіряти назви змінних (семантику) до запуску програми. Це може робити IDE, але реально юзабельним, яканамене, є тільки RubyMine, яке дійсно потужне, але не безкоштовне. Якщо DRY-їти код, то ця ймовірність помилки скорочується, адже скорочується жц змінних, але це не легко для новачків.
    Цей мінус, імхо, значно підвищує планку входження, тож, я б не сказав, що Ruby — легкий в вичнанні, — це скоріше мова для вже досвідчених розробників.

    Поддержал: Владимир Воробьев
  • Топик для поиска работы

    Привет!
    Ищу помощника/стажера (не команду!) в проекты с использованием чипов Espressif ESP32 и ESP8266, популярных в секторе IoT. Идеально — студент ИТ специальности или выпускник.
    Основные требования: знание C и Git, отсутствие комплексов перед проводами, шнурами, батарейками, диодами и т.п., — требуется работать с железом! Необходимы лишь базовые знания в электронике, без использования паяльника.
    Работа в Linux (Ubuntu) или Mac.
    Стэк: C, FreeRTOS, GCC, Git, Eclipse.
    Задачи: реализация модулей по заданию.
    Проекты — разные, обычно продукты на стадии MVP, но есть и продакшн. Разработка в основном состоит в использование таких технологий как WiFi, Bluetooth, «железных» интерфейсы UART, SPI, GPIO, I2C и др. А также взаимодействие с AWS, custom backends. В принципе, можно выбирать с чем работать: либо ближе к железу, либо протоколы высших уровней.
    Знание английского — лишь в рамках работы с документацией. Работа удаленно, частичная занятость с перспективой полной. Оплата соответсвует начальному уровню.
    Важно, чтобы Вы имели желание развиваться в данном направлении.
    Если интересно — пишите мне на atlascoder@gmail.com.
    Меня зовут Антон.
    Удачи!

  • Problem Solving: методики

    Если не известны А и Б, значит нет проблемы) Хотя это, конечно, зависит от постановки задачи: ведь проблемой может быть отсутствие проблемы, но и в этом случае, кажется, состояние Б — известно))
    Гораздо чаще бывает так, что А и Б — известны, но вот почему не получается достичь Б — сложно определить. Минимальная польза методик, возможно, сотоит в том, что они позволяют более широко посмотреть на систему, выйти за привычные рамки. Например, очень условно, можно искать проблемы в коде, или грешить на чью-то квалификацию — определять тривиальные причины. Но реальная причина может быть в том, что кому-то не выгодно завершать проект. И ставить подобные вопросы, даже самому себе, — бывает очень сложно.

    Поддержал: Denys Kostin
  • Problem Solving: методики

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

  • Нужны ли технические навыки менеджеру проектов?

    Есть мнение, что эффективный менеджер и успешный менеджер — не одно и то же. Эффективных менеджеров обычно не очень видно, но без них — процесс деградирует, а вот успешных — видно издалека, но если их убрать — все продолжает работать.
    «Софт-скилз» точно помогут быть успешным, но без технических знаний врядли можно быть эффективным. В идеале, конечно нужно и то и другое, но в реальности это редкость.

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

    То есть эффективность зависит от отрасли и специфических ей знаний. Менеджер строительных проектов сможет перейти в ИТ-проекты, и наоборот, но он будет менее эффективным, чем ранее, какими бы «софт-скилз» он ни обладал.

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

  • Задачка для 3-го класса, или ПМ не ПМ

    Можно найти в книгах по ПМ указания на исследования, что многозадачность менее эффективна, чем доведение задачи до конца и переход к следующей. Потеря эффективности объясняется затратами на переключение контекста. Эта идея также положена в принципы Lean, Kanban, Agile, где переключение контекста — мусор, т.к. не увеличивает создаваемую ценность.
    Но в реальности, это больше относится к специалистам, тогда как работа менеджеров всегда фрагментарна: решение конфликтов, проблем, поддержка связей и т.п. — все это выполняется постоянно в изменчивом контексте, хотя кажется, что решается одна главная задача.

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

    Поддержали: Eugen Maevsky, Gluttton
  • Технический долг: профилактика и погашение

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

    Если организационное решение об использовании костылей принимается без заказчика, то и обосновывать затраты становится сложно.

    Поддержал: Dmytro Lapshyn
  • Уровни абстракций — ключ к пониманию архитектурных изысков ПО

    Очень доступно! Здрово!