Java Developer
  • Внести собственные улучшения в проекта заказчика? — Нет

    Ви написали, в цілому, може й вірно. Але я б не хотів працювати в компанії з таким підходом. Занадто багато бюрократії. До того ж ви описуєте самий довгий шлях, а подаєте його як найкоротший.

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

    Якщо ж в сфері компетенції іншої команди — знайти їх ліда і «продати» ідею туди.

    Якщо ж фіча десь на межі ( щось там з апі, наприклад ), то можна обговорити на мітингу і якщо ок, то одразу йти чи самому чи з лідом до іншої команди чи до «найменшого спільного кратного», де приймається рішення.

    Взагалі, якщо рішення приймаєш не ти, то є сенс одразу йти до того, хто його приймає ... і чим менше «посереднків» тим краще. А там вже вирішиться чи треба там аналітик/дизайнер чи ні.

    Ну і якщо це зовнішній клієнт, треба дивитись на те як організована робота в цілому. Можливо є сенс продати фічу клієнту одразу і на рівні «виконавець-виконавець» і потім вже підняти її на рівень sales. Але знову ж ... по обставинам.

  • Подскажите полноценный курс для разработки для STM32 Nucleo F7

    З карантином — то лажа, згоден ... але з ним багато де лажа.

    Для старту, такий офлайновий курс, в Києві після роботи — саме воно.

    По онлайнових курсах, так не підкажу.

    З іншої сторони, якщо якась база у вас є, то sdk, examples, reference manual і вперед розбирати периферію за периферією.

    Скачал среду en.stm32cubef7_v1-16-0.zip Внутри даже нет экзешника, чтобы установить ее или запустить

    www.st.com/...​t-tools/stm32cubeide.html
    Тут, наче як, остання ... там під win звичайний інсталятор.

    Але в embeded з ide кругом біда ... тому cube ide ще дуже навіть гарний інструмент.

  • Подскажите полноценный курс для разработки для STM32 Nucleo F7

  • Не відображаються українські символи в Flutter (і,ї,є,₴)

    Ви ж в курсі, що то помийний сайт?

    Оригінал тут: stackoverflow.com/...​ish-character-doesnt-work

    Підтримав: Not Sure
  • Співбесіда з PHP. 250+ запитань для Junior, Middle та Senior

    Цікава підбірка ... знайшов декілька запитаннь, що часто ставлю сам :)

    І декілька, які знадобилося погуглити )

    Цікаве питання про Bloom filter. Я спершу не згадав що це, але як почав читати, зрозумів, що це та ж фігня, яку використали в signal для contact discovery. Я б сказав, що це дуууже нішеве питання.

    Підтримав: Volodymyr Yefremov
  • Какой стек backend+database вы бы рекомендовали?

    Я б розглянув варіант не вбиватися в академічну реляційну БД.

    Один тариф на місяць для всіх номерів влізе в один json.

    При бронюванні, тариф з усіма даними копіюється в замовлення так щоб не тримати зв’язок на «зовнішнє» джерело даних.

    Єдине, що для такого підходу треба обирати backend, де можна в пам’яті тримати гарно розкладений той json в зручну in-memory структуру, яку постійно всю тримати в пам’яті (щось схоже на кеш).

    А самі json-и, можна навіть в gzip тримати в blob в БД, там і версіювати.

    Мінус такого підходу в тому, що треба забути про запити всередину того json. Але плюсом є те, що структуру можна зробити «природною» для даних, in-memory буде працювати дуже швидко, а БД буде дбати лише про «persistance».

    Підтримав: Vlad N
  • Ошибки в архитектуре ПО и как их избежать. Часть 1

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

    Питання не розкрите. З наведеної аргументації схоже, що «преференції» однії людини поміняли на «преференції» іншої.

    количество активных пользователей выросло в 10 раз. Тут и начались сложности.

    Ще не було системи, яка б таке пережила без доробки.

    Метрики не збирали — бо не треба було і за це не доплатили ... та й не знали що збирати.

    Проблеми з SQL не проявляють себе на малих даних. Доналаштування БД при зміні об’єму даних — стандартна процедура. Щоб передбачити ріст в 10 разів, треба було нагенерити в базу в 10 разів більше даних на тестах. (За тестування під навантаженням, скоріш теж не заплатили, того і не зробили).

    Я вам більше скажу, зросте кількість даних ще в 10-100-1000 разів, база, майже напевно, знову підведе.

    А также точно оценить задачу, учитывать перспективу развития проекта через 2, 5, 10 лет.

    Це неможливо. Щоб проект жив 2-5-10 років і витримував зміни, потрібна компнда розробників в штат (або на підхваті в аутсорсі).

    В итоге при создании каждого объекта на сторону приложения вытягивалась добрая половина базы данных.

    Проблема з ОРМ часто полягає в тому, що розробники ОRМ вирішують додати туди зайвого функціоналу, який чомусь люди вважають, що необхідно використовувати.

    Основна задача ORM — це mapping: ResultSet на об’єкти, об’єкти на інсерти, ще мож щось з процедурами.

    Query Builder — це вже не задача ОRМ, хоч і для специфічних задач ще згодиться.

    А ось join-и, витягування дочірніх об’єктів, генерація запитів, hibernate-івські сесії — це все те, чого варто уникати — ці всі інструменти створюють більше проблем, ніж вирішують.

    Базу даних треба поважати: писати складний SQL руками.

    Не забывайте грамотно разбивать свою систему на слои.

    Шари — це добре. Але в більшості випадків, це є сенс робити на етапі рефакторингу, коли стає очевидним де і що є сенс розділяти. Інакше ж, створиться мінімум по три об’єкти на кожну сутність (dao, dto і, власне, модель) і купа перетворень між ними. В результаті, вагон класів і каша в коді.

    Шари — це добре, але Keep It Simple.

  • JavaFX vs HTML + CSS + JavaScript

    Fxml — то добре ... але це не парадигма, це інструмент. Тому змішувати там більш ніж норм ... а нагавнокодити можна і змішуючи і не змішуючи )

    Підтримали: Olexandr, Dmitry Bugay
  • JavaFX vs HTML + CSS + JavaScript

    Ну ... javafx — це ж як раз і є UI фреймворк.
    Всякі «Licence agreement» можна і у web view зверстати. А UI — засобами фреймворку. Зрештою, в javafx стандартна архітектура ... нічого незвичного. Єдине що візуального редактора там не дуже ... scene builder ... трохи ... з особливостями.

    Підтримав: Olexandr
  • JavaFX vs HTML + CSS + JavaScript

    WebView в JavaFx — це ще той тормоз ... just in case.

  • А ти точно senior?

    матрицю транспонував в універі,

    Це не зовсім так ... наприклад, жорданову форму матриці я зараз ось так не згадаю і не зроблю, оскільки після курсу лінійної алгебри жодного разу не використовував. Цей «м’яз» все-рівно треба качати ) Він не так швидко атрофується, але атрофується.

  • А ти точно senior?

    є «фундаменталс» і досвід, який не незнецінюється, на відміну від знання «модних фрейморків».

    Хех ... це вірно, і це та думка, яку я часто намагаюсь донести. Але на фундаментальних знаннях в нас хайп не ловлять, нажаль.

    Якщо повернутися по моєї початкової тези, то я говорив про досвід зрілого розробника в якійсь технології.Тобто, вже маючи якийсь фундамент в, наприклад java, можна мати рік досвіду в C#. І теза полягала в тому, що, наприклад, 5 java+1 C# не сильно відрізняється (в знаннях C#) від 5 java + 5 С#.

    Ну і, fundamentals та досвід ... то як м’яз .... накачати важко, підтримувати легше але вимагає постійної роботи, а якщо нічого не робити, втратити тонус дуже легко.

  • А ти точно senior?

    Це абсолютно вірно ... але суть в тому, що ці шишки та граблі дуже швидко забуваються і через рік-два «десь я таке робив ... треба глянути отой репозиторій», а через 5 ... ну ... 10 років тому я писав на C# ... я зараз, звісно, можу писати на C#, можу поправити щось в старих проектах ... але, щоб по нормальному там щось робити, треба розбиратися заново. Ну і про граблі та шишки я там слабо вже щось пам’ятаю.

    Тобто, кінець-кінцем, мілкі граблі «новачком» гугляться на stack overflow за хвилину, а більш важливі тренують в людини відчуття того що є добро чи зло в сфері. З часом це все сильно обезцінюється. Тому я і дав людині з більшим досвідом 15-20% «чогось» більше, хоча на відрізку 2-5 років це може бути і 5-10% а то і менше... По суті, немає чого вчити майже в будь-якій сучасній технології більше року. Решта часу — то збільшення кута зору, просвітлення, війна добра зі злом, прекрасного з огидним, тощо.

  • А ти точно senior?

    якому рік від народженя

    Найбільш ризикованим для нас був не gitlab. Ризикованим був flutter, якому як раз і був рік від першої версії. Тоді і мова нова, архітектура UI ні на що не схожа, купа ліб під одну задачу і майже всі в беті та з github-а з малими community.

    Це був дійсно ризик ... але пройшло вже понад рік, і я вам скажу, що кращої платформи для розробки UI я ще не бачив на своєму скромному шляху (якщо порівнювати з Delphi, MFC, Windows Forms, WPF, JavaFx, HTML+CSS+JS, Android, Swift).

  • А ти точно senior?

    тягнути github ci, якому рік від народженя

    В нас був CI на Bamboo до того.
    Після нього CI на gitlab — це був ковток свободи і свіжого повітря. Виправдав себе практично через місяць. Тільки що варте білди в контрольованих середовищах в docker контейнерах. Зараз у нас всі білди в контейнерах, крім ios. І коли ми налаштовували на ios runner, я згадав, що то за пекло, коли тобі потрібно обслуговувати runner (то версію чогось міняй, то на диску щось видали, то система якесь оновлення просить).

    Щодо нового інструменту ... на self hosted gitlab ми перейшли на початку 2016го, на gitlab ci десь через 11 місяців. ± десь і тоді починали впроваджувати контейнеризацію по серверах. Я вам скажу, в цих всіх «нових» технологіях ми не зіштовхувалися з «непереборними багами». Були відсутність якихось фіч, які б дуже хотілося, але то таке.

    скрипти в бранчах

    Це одна з основних переваг — проект розвивається скрипти міняються. Завжди можна зробити будь-який білд будь-якої версії і все буде коректно.

    VSTS була якась

    Я вийшов з microsoft-ського стеку десь в той час, коли тільки цей інструмент випускав свої перші версії. Тому предметно порівняти не зможу.

    І скільки людьских місяців праці витратилии на написання екшнів і розмноженя воркфловів по репам ?

    Не зовсім зрозумів питання, якщо чесно. Звісно на те, щоб .gitlab-ci.yml + обв’язку до нього зробити знадобився час. Але на той момент нам багато і не треба було. Я б не став міряти місяцями. Та й еволюціонували білд скрипти з проектом. А той час, що ми потратили, був з запасом зекономлений на білдах-тестах-деплоях.

  • А ти точно senior?

    Ми стараємось на старті кожного нового проекту робити якесь review технологій/підходів. Саме на таких рейках ми впроваджували dagger (server side), java modules, prometheus, gitlab ci, kotlin (server side), http api на корутинах, так ми перейшли на з java android на flutter, тощо.

    Якісь речі/підходи портуються на старих проектах, якісь плануються портувати, якісь ні, якісь проекти «працюють і добре». По технологіях треба ходити ... проекти треба портувати/переписувати ... інакше, дуже швидко стек безапеляційно застаріває і потім і проект підтримувати стає дуже важко (як от в нас є одне java 8 32bit (що вже пару років як треба в deprecated), яке важко кудись зсунути), так і навички залишаються там же.

    А працювати коли

    Навчатись через роботу, працювати через навчання, навчатись після роботи, жити в проміжках між усім цим). «Вічний студент» — це наше прокляття ))

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

  • А ти точно senior?

    З усього, що я прочитав тут, як на мене, ми маєм не достатньо інформації для такого висновку.

    З іншої сторони ... чим відрізняється досвід зрілого розробника 1 рік технології Х від 5 років? Як на мене, той що 5 років працює буде знати ну від сили на 15-20% більше і то далеко не факт.

    Винятки з попереднього є (в основному науковомісткі, чи мож hardware близькі), але точно не у вебі.

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

  • А ти точно senior?

    Критикувати цю таблицю можна, адже вона виписана через призму досвіду однієї людини. З однієї сторони там є дуже специфічні речі, от як cdn (поки раз-другий не зробиш — знати не будеш... там ой як все не просто), з іншої сторони, можна знайти речі, які тут не згадані (якщо мова про веб, то нехай web socket чи webgl).

    Але в цілому, має право на життя.

    Мене дивує реакція багатьох коментарів. Адже битий розробник, як мінімум з 80% цього всього мав би бачити на своєму шляху .... і не тільки цього а й ще стільки ж.

    Шановні «senior»-и, вважайте цей перелік нижньою планкою. Якщо ви щось вважаєте тут непотрібним знати, можете помігяти на щось рівноцінне (наприклад, той самий cdn на webgl).

  • Навіщо дотримуватися документування на проєкті і хто це повинен контролювати

    Висловлю не дуже популярну думку: я б не радив зловживати документацією, адже це дорого і рідко ефективно.

    Як на мене документ є сенс писати, якщо зрозуміло хто його буде читати, зрозуміло навіщо, і зрозуміло, що читати таки буде.

    Все решта дуже швидко старіє.

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

    І, в цілому, варто зауважити, що писати чи не писати є сенс обговорювати щодо кожного конкретного документу в кожному конкретному проекті.

  • Data Science и Machine Learning: с чего начать и где учиться

    Я б тут розділив задачі та застосування.

    Задачі можна, умовно, поділити на картинки, тексти, аудіо, решта.

    Застосування ж бувають дуже різні: grammarly (тексти), ring (відео), розпізнавання голосу, автогенерування субтитрів, рекомендації товарів/відео/музики, sense.com (аналіз енергоспоживання), та ж фотофіксація перевищення швидкості, deep fake, та ще купа всього.

    В суто ж маркетингу, там більшість роботи з даними не виходить за межі екселя. І хоч excel — це монстр, що перернув світ, але я б не відносив його до інструменту data science.

← Сtrl 123456...24 Ctrl →