Java Developer
  • «Ну ма-а-ам... я більше так не буду», або Про веселе життя PM’а

    Діте теж люди ) І вони теж хочуть вчитися/працювати/заробляти.

  • Как мотивировать сотрудников компании учиться? Три инициативы Gamingtec

    свободное время без тасок

    Хіба таке буває? На роботі треба працювати. Навіть в самі халявні часи є технічний борг, який треба фіксити.

  • Грн за дол на кінець 2020 року

    Не обліковою ставкою єдиною ... або я не до кінця вас зрозумів, або ви орієнтуєтесь на підручник першого курсу з економіки.

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

    З того, що я знаю, в нас аналітику або купують, або роблять в великих екселях.

    Наступний етап: всякий ML, але про нього в економічних моделях поки не чув.

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

  • DevOps майбутнього: що зміниться та як це вплине на професію

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

    1. Поділити на 10 ІТшників та поділити на три залізо — то серйозна заява. Це схоже на не-ІТ компанії з софтом з 90х, які не можуть вилізти з зоопарку софта, технологій та старих рішень.

    2. Якщо я вірно зрозумів вашу тезу, то шукають те, чого немає: стандартизованого cloud.

    3. Виктристовувати cloud це часто корисно. Особливо в допоміжних сервісах. Але щоб в усьому... хз.

    Могли б ви з досвіду назвати 2-3 use case-а, коли перехід в cloud був би виправданий, за умови, що за альтернативу взяти редизайн системи на власних потужностях? (Якщо не рахувати речі типу SaaS як crm, ту ж пошту, трекери задач, office 365, тощо ... особливо, якщо бізнес не ITшний)

    Підтримали: Oleksandr Katykhin, Semen Drobakha
  • DevOps майбутнього: що зміниться та як це вплине на професію

    Важко погодитись з вашими висновками.

    Візьміть приклад з розробки ... колись був IDE з Borland Pascal, зараз є JetBrains. Чи вплинув цей перехід на розробку? Очевидно, що так і досить суттєво. Чи змінило це сутність роботи? Думаю, що не дуже.

    З «DevOps» переїзд між голий linux->віртуалки->докер по суті спрощує та пришвидшує деякі процеси, але, знову ж, на скільки принципово?

    Щодо cloud ...
    1. Сервіси як такі — далеко не новинка: mail, dns, sms gateways існували вже дуже давно як сервіси. Зараз їх асортимент, просто, розширився.

    2. Хмарні сервіси не стандартизовані. Відповідно, їх використання — це вже vendor lock in. Особливо це важливо, якщо використовувати специфічні фічі.

    3. Часто, є зручним розмістити щось там на VPS. Але як тільки появляється яке не яке навантаження, одразу чомусь вигіднішим стає взяти в оренду виділений залізний сервер.

    4. Є фічі, які cloud провайдери дозволять робити значно легше і краще, ніж самостійно: cdn, масштабування, частково бекапи. Але, знову ж, це дорого під навантаженням. І можна прийти до думки, що простіше взяти по серверу на кожному континенті в оренду.

    5... В хмарних рішеннях, звісно, є сенс для деяких задач. Але із-за 1-4 я не розумію хайпу навколо цього. Що б там не було, але точно не про «дешево» та не про оптимізацію витрат.

  • 5 ошибок при внедрении OKR

    Не зовсім... Якщо ви менеджер з продажу, чи підприємець, який думає як заробити більше — то так. Якщо ж ви код пишите, то й цікавитись цим було б доречно. Якщо ж не цікаво ... ну ... йдіть в sales.

    Можна ставити питання як себе продати... але щоб було що продавати, знову ж, треба рости професійно.

  • Macbook 2019 16″ — как вам?

    Продукція Apple, в основному досить якісна, хоч і дорога.

    Але всім рекомендую її НЕ купувати.

    В них погана філософія: все закрите, все платне, все не сумісне ні з чим, крім своїх ж продуктів.

    Розвивався б світ ІТ з такими принципами, ми б зараз не мали б і, напевно, половини досягненнь, які є сьогодні.

  • 5 ошибок при внедрении OKR

    В тижні 7×24=168 годин. В середньому, для нормального сну треба 56 годин. Робочий тиждень 8×5=40 годин. Їжа, душ і інші фізіологічні потреби десь 3×7=21 годину. Час на дорогу дім-робота хай 1.5×5=7.5 годин.

    Залишається 43.5 годин на особисте життя, навчання, відпочинок, тощо.

    І тут ви описуєте людину, яка майже половину (40 з 40+43.5) свого активного часу виділяє на діяльність, в якій зовсім не зацікавлена, не має амбіцій та інтересів?

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

  • На що звернути увагу ІТ-спеціалісту під час підписання договору із замовником. Поради юриста

    Є декілька питаннь, якщо у вас є бажання відповісти.

    1. Ви рекомендуєте підписувати акти та додаткові угоди. Розумію, що є така «традиція», але все-таки хотілося б розуміти як організувати процес з мінімальним документообігом або без нього взагалі.

    2. Договора в електронній формі. ЕЦП круто лише в межах України і то не дуже й то популярно. Як укладати договора віддалено з іноземцями? Чи мають скани з підписом однієї сторони якусь юридичну силу?

    3. Про інтелектуальну власність ... на скільки я розумію, довести, що той чи інший код чи макет чи інший продукт інтелектуальної праці був зроблений в межаж угоди і є власністю замовника — неможливо. Будь-які «цифрові сліди» як то логи, коміти, тіккети є такими, що можна підробити. Що заважає працівнику скачати собі весь код і потім заявляти, що він його сам зробив вечорами вдома, а в актах взагалі не про це йдеться і компанія сама краде його працю? Не хеш-суми ж архівів/комітів в актах вказувати? І навіть якщо так, чи приймє суд хеш-суму в акті як доказ?

  • DDoS-атака на RDP-службы: распознать и побороть. Успешный опыт от Tucha

    Як ви збирали статистику запитів по всій мережі? Щось типу DPI на роутері? Чи агенти на серверах з RDP, що зливають логи підключеннь?

  • Советы для начинающего Java-разработчика. Подготовка к собеседованию — часть 2

    Не міряв метрик, якщо чесно, в таких розрізах. Та й проект/репозиторій далеко не один.
    Якщо взяти найбільший, то можу дати такі дані:

    — 1946 java файлів на 13Мб суто java-коду. Класів, відповідно, більше, якщо врахувати вкладені. Це лише java. А ще є php з адмінкою, crud-ами, тощо.

    — транзікційнійсть ... в межах однієї бази даних транзакціями, як не дивно ... між різними системами, той, хто ініціює «транзакцію», відповідає і за те, щоб опитати всі інші сервіси і довести транзакцію до кінця або скасувати її ... такий собі eventual consistency на скінченних автоматах ... це якщо я вірно зрозумів ваше питання.

    — про глобальні події я не сильно зрозумів про що ви ... якщо про щось типу event bus, то в чому проблема взяти RabbitMQ ? ... хоча в нас його і немає. В деяких сценаріях ще ZooKeeper може бути.

    — щодо сутностей ... сутності різні бувають ... якщо ви про БД, то 127 таблиць в них в сумі 919 полів, в найширшій таблиці 64 поля.

    — що ви розумієте під вкладеними колекціями теж важко зрозуміти ... відношення 1:N в БД? якщо поля я порахував grep-ом, то тут так прикинути не вийде :) ... є і 1:N і N:N і їх ніхто не рахував :)

    — lazy loading теж різний буває ... якщо ви про те, що разом з об’єктом підвантажуються всі foreign key-ї (чи lazy чи ні), то такого не робимо взагалі. Якщо треба перейти по foreign key, робиться явно ще один запит — корона не злетить. З такої точки зору, більш lazy не придумаєш :)

    З однієї сторони, проект, дуже навіть не малий. З іншої, 127 таблиць в БД не так і багато, якщо порівнювати з «деякими». Але, ви знаєте, проектував би зараз, старався б архітектуру розбити хоча б на 2-3 менші сервіси з меншою кількістю таблиць. Наприклад, 100% виніс б всю бухгалтерію кудись подалі, так як вона «погано впливає» на архітектуру в цілому, так як міняється кардинально і часто.

    Хотілося б зрозуміти, що відповіді на ці питання вам зможуть пояснити?

  • Советы для начинающего Java-разработчика. Подготовка к собеседованию — часть 2

    Якщо чесно, об’єктивно відповісти важко, оскільки зі spring не працював ... лише читав про нього.
    Тому круто було б, щоб ви прокоментували мої аргументи:

    1. Щодо netty ... тут можна написати будь-що з будь-яким мережевим протоколом ... але це не чесне порівняння. Щодо http ... можна зробити long push, можна зробити обробку запитів в корутинах (з котліном), а можна і звичайний веб-сервер (що трохи громоздко).

    2. SparkJava — стартує в пару стрічок і зробити API на пару викликів — просто і швидко.

    3. Щодо HTTP API в цілому ... більшість таких API в нас мають «свій» спосіб підпису запитів та серіалізації. В результаті, робота з http сервером зводиться до невеликої обгортки, яка роутить запит вже по власноруч написаним класам ... і тут абсолютно все-рівно, що там під капотом чи netty чи sparkJava чи щось інше на свій смак, так як робота з цим середовищем робиться лише в двох-трьох файлах.

    4. Application server-и ми не використовуєм. Сайти пишем на php, а не на java, тому http весь — це лише server2server api.

    5. Щодо dagger ... він compile-time і генерує код, який можна читати. Швидше не напишеш. Конкурентів немає. Не бачу сенсу в іншому підході до dependency injection.

    6. gRPC — працює мегашвидко порівняно з REST. Клієнт і сервер генеруються для купи мов програмування. Дуже швидко і безболісно пишеться як сервер так і клієнт. Мінус: в браузері не буде нормально працювати, немає аналога curl, postman, тощо.

    7. Щодо бази ... є така ідея, що «базу даних треба поважати». Hibernate, в цих термінах, її «не поважає», і тому з ним проблем більше, ніж рішень (ми пробували лише в одному проекті ... не виключено, що невірно застосували). Але цей пункт краще винести в окреме обговорення, так як гарного рішення «а як, все-таки треба робити» в мене зараз немає. Найбільш адекватним ORM, з моєї точки зору, для java є гугловський Room під Android, але то лише під Android. ... хоча дивлюсь тут jdbi пропонують ... треба глянути до нього ... виглядає непогано на перший погляд.

    Щодо фіч spring-а, які, можливо, були б корисні, але в нас явно немає:
    — Все таки вирівняна та стандартизована екосистема підходів.
    — AOP виглядає круто, хоч і громоздко і привносить в проект магію. Не знаю, що там на практиці з ним, але як мінімум є така можливість і вироблені практики.
    — Кругом обіцяють, що має вийти testable код. Якщо так, то круто. Але відчуваю, що безкоштовного сиру там немає.

    Підтримали: Yegor Chumakov, Pavlo Chechehov
  • Советы для начинающего Java-разработчика. Подготовка к собеседованию — часть 2

    Dagger для dependency injection,
    Netty для «крутого» сервера,
    SparkJava для «простого» http сервера,
    gRPC для RPC замість REST...
    Це коротко про те, що в наших проектах є.

    З Hibernate гірше ... їздимо на своєму велику поверх jdbc. Треба якось довести до розуму його і викласти в open source.

    Підтримав: Yegor Chumakov
  • Генерація SQL-запиту засобами MySQL-сервера

    Схоже, що ви пишите ці тези базуючись не лише на тезах університетського курсу по БД.
    Тому, хотів би почути вашу думку з приводу наступного ....

    Великі і потужні БД (той ж oracle) — це дійсно витвір мистецтва. І щоб там відверто не накосячити на великих схемах там дійсно вистачить роботи, щоб цим займалась окрема людина, інколи навіть команда. Це я до того, що я не заперечую те, що в таких випадках DBA є сенс сприймати як повноцінний напрямок роботи.

    З того, що я знаю, серйозні БД круто працюють, коли працюють на одному сервері. Тому, з ростом, цей сервер розганяють дисками, процами, пам’яттю стільки, скільки це взагалі можливо (хоч це не пропорційно дорого). З якогось моменту, а може й самого початку додають кілька реплік ... для всяких бекапів, аналітики та read-only запитів чи навіть fail-over (ще один дорогущий сервер). До цього моменту «все нормально». А далі починаються проблеми, проблеми з multi-master рішеннями, проблеми з шардуванням на рівні БД, тощо. Це все складно та працює не так швидко, як хотілося б. Перехід з «одного сервера» на якийсь варіант з кластером, наврядчи можна нормально зробити без змін в підходах як до архітектури самої БД так і до логіки роботи з нею самих додатків.

    З іншої сторони, можливим варіантом є відмова від централізації БД. Коли вимоги до масштабування звалюються не на плечі БД, а закладаються в архітектуру самого додатку. В цьому випадку, не виключено, що кожна «нода» такого додатку сама по собі буде мати «свою» БД. Не виключено, що якісь дані (що рідко міняються) і будуть лежати в multi-master кластері. Не виключено, що для певних операцій (наприклад, лог транзакцій) і будуть використовуватися специфічні рішення (наприклад, kafka). Можливо, що навіть в фінансових сферах класичний ACID не такий вже і важливий (подивіться як працюють еквайрингові системи ... там операції по банківських картках точно не ACID ... той самий eventual consistency може досягатися навіть через кілька днів).

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

    Знову ж, суб’єктивно, я більше схильний використовувати прості open source бази, ставити до них прості вимоги, і якщо навіть колись якась фігня станеться і треба буде мігрувати, ... це не буде проблемою, так як «не сильно то й ми від бази багато хотіли, те що нам треба вміють всі». А якщо такі рішення не тримають навантаження, значить треба думати як зробити навантаження меншим, чи винести його в іншу форму, чи обробляти іншим чином, чи розподілити його якимось способом...

  • Генерація SQL-запиту засобами MySQL-сервера

    Ееее... то історія з іншого світу ... в нас тут стартапи і все таке ))

    1. Це принципово нічого не міняє. Райський простір ACID операцій кінець-кінцем або тріщить по швам, або стає занадто ресурсоємним і дорогим.

    1.1. (сарказм) Це призводить до дорогих БД на дорогих сертифікованих серверах з дорогими сертифікованими обов’язково рейдами в дорогих сертифікованих датацентрах, які обслуговують дорогі сертифіковані девопси/адміни/мережеві інженери, і якими управляють дорогі сертиіфковані DBA.

    2. DBA на базі до одного гігабайта (якщо ви подивитесь вище по дискусії — там йшлося про такі випадки) — не занадто?

    3. Те, що віддати розстановку індексів та написання купи процедур на сотні стрічок окремій людині, по суті мало що змінить. Задачі — ті ж. Інструменти — ті ж. Проблеми — ті ж.

    4. Напевно, основне ... не завжди, але часто, великі проблеми з БД вирішуються не на рівні БД. Тому окремий DBA не допоможе, а навіть зашкодить, так як потрібна буде людина, яка знає «що там в БД» і знає «що там поза БД».

    Підтримав: Alexander Shapoval
  • Генерація SQL-запиту засобами MySQL-сервера

    З свого досвіду, різниця є ... і їх декілька:

    1. поняття ціліснісності БД часто виходить за межі самої БД і все-рівно треба про це думати на рівні додатку, незалежно від того є там процедури чи немає.

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

    3. Якщо потрібен таки query builder, то не факт, що в процедурах вийде лаконічніше (наприклад, у випадку типу «а чи треба join-ити отой підзапит»)

    4. В додатку, при потребі, можна організувати кешування різного роду, об’єднання insert-ів, додаткову синхронізацію, тощо

    на відміну від декількох клієнтів з однією БД, де збережені процедури матимуть перевагу.

    Це саме той випадок, коли я з вами погоджуся. А саме, коли ці клієнти писані різними командами, в різний час та на різних мовах. Це саме той випадок, коли БД перетворюється в такий собі «мікросервіс», який і доступ контролює і правила роботи з даними задає. Питання чи повинна цим займатися БД є відкритим та реторичним.

  • Генерація SQL-запиту засобами MySQL-сервера

    я не розумію чому саме вам довелось кривитись?

    Вважайте, що це суб’єктивне враження :)
    Просто, згадувавлися не дуже приємні епізоди колупання з БД, що пов’язані з надмірною вірою в те, що оптимізація запитів в СУБД знає що робить і обирає дійсно найкращий спосіб виконати запит чи процедуру.

  • Генерація SQL-запиту засобами MySQL-сервера

    Гарна стаття... було б круто щось таке прочитати, коли самому треба було написати пару процедур/трігерів. Пам’ятаю, ще тоді було проблемою знайти нормальну документацію по цих речах.

    Все, наче, круто... якби не одне «але». Читаючи цю статтю, довелося декілька разів скривитися. І причин цьому декілька.

    Я бачив, умовно, три «види» БД.
    1. Малі бази. Це бази, які наврядчи доростуть до гігабайта. В таких базах можна робити, умовно, все, що заманеться. Якось, кінець-кінцем запрацює. Таких баз більшість і до них входять мільйони різних веб ресурсів. Тут можна розважатись як хочеться: і тригери і прцедури :)

    2. Бази з великою кількістю логіки. Тут сотні таблиць, близько до нормалізованої форми, проставлені вторинні ключі, купка процедур, можливо і бібліотек процедур, а може і з тригерами. Це, буває, схоже не на БД, а на невеликий мікросервіс з своїм API у вигляді процедур. Такі академічно зроблені бази я бачив в банківських системах.

    Все, наче, круто .... але така БД їсть багато ресурсів .... і, що біда, багато ресурсів одного сервера. Горизонтально масштабувати — майже неможливо (хто б що не говорив про реплікацію і подібні речі).

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

    3. Бази з великою кількістю даних. Зазвичай в таких базах все на стільки просто на скільки це взагалі можливо. Кожен крок продуманий так, щоб не дай боже щось не затормозило. Якщо десь і є процедура, то цей крок явно прорахований і ця процедура робить рівно те, що ефективно робить БД. Тут, часто використовують і NoSQL і якісь спеціалізовані речі.

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

    Для великих колекцій та ж mongoDb буде значно швидша на вставку та вибірку по ключу, наприклад. Та й кластеризація там з коробки яка не яка. Тому тут будуть всі колекції, які помірно ростуть.

    Для логів/журналів/аудит-логів: kafka та/або elastic search.

    ----

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

    Підтримали: Dmitry Kapustin, Valeriy Shvets
  • Корупція в ІТ-вишах 2019: хабарництво при вступі зменшилося втричі після введення ЗНО

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

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

  • XSLT-шаблонізатор для PHP

    А для чого на php шаблонізатор, якщо php і є шаблонізатор? :)

    Підтримали: Serj_by Public, Aliaksandr Valialkin
← Сtrl 1... 34567...24 Ctrl →