Java Developer
  • Высшее образование в сфере кибербезопасности в Украине

    Не зовсім відповідь на ваше питання .... але techmaker.ua/appsec.html розглядали? (звісно, що це не є вища освіта)

  • PHP дайджест #20: PHP в 2019, прийняті RFC, 7.4 уже вийшов

    1. Дивно про «voting», адже далі «This poll has been closed».

    особенно для проектов с несколькими языками

    У вашому досвіді зустрічалися випадки, коли дійсно по тексту після < ? ви визначали що то за мова? В моєму — ні ... Це ще одна неіснуюча проблема як і з xml?

    Щодо решти ... про < ?= питання не стоїть. Це добре, що хоч це не чіпають. Хоча всі ваші аргументи проти < ? з таким самим успіхом можна застосувати і до < ?=
    Питання стоїть за та їм подібні.

  • PHP дайджест #20: PHP в 2019, прийняті RFC, 7.4 уже вийшов

    1. Так, наче, як раз прийняли: wiki.php.net/...​/deprecate_php_short_tags

    2,3,4. Круто, що знайшовся хтось з протилежною думкою. Дуже цікаво почути вашу аргументацію. Якщо НЕ вважати аргументами «проблему з xml» та «адмін на сервері не налаштував коніфг», чи можете навести причини чому «является говнокодом»? Адже навіть в RFC толком не навели аргументацію. Ця дискусія схожа на маленьке полювання на відьом по релігійним переконанням.

    З моє сторони, насправді, є лише один арумент «за»: це ті самі шаблони.
    < ? if (...) :?> ... < ? else: ?> ... < ? endif ?>
    значно краще та лаконічніше виглядає ніж
    < ?php if (...) :?> ... < ?php else: ?> ... < ?php endif ?>

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

    Смешно просто

    Давайте без постправди))
    Ви дійсно шаблони пишите без шаблонізаторів і так вважаєте?
    З мого досвіду в більш-менш складному шаблоні, цей відкритий тег < ?php починає просто нагромаджувати код і виїдати око.

  • PHP дайджест #20: PHP в 2019, прийняті RFC, 7.4 уже вийшов

    Що ж цей short_open_tag так чешиться?

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

    Якщо зараз php з short_open_tag та з конструкціями типу if/endif є досить гарним шаблонізотором, то без short_open_tag шаблони вже занадто нагромадженими будуть. Ще декілька таких змін і php перестане мати якісь переваги над іншими мовами для веб розробки .... ехх (((

    Підтримав: Mykhailo Lozynskyy
  • ORM Сначала классы, потом таблицы

    Базу даних потрібно «поважати» ... вона все-таки зберігає для вас ваші дані :)

    БД — не проста штука. І коли даних багато і складних, треба вирішити як з ними швидко працювати. І тут логіка починає тягнутися: в sql створюються денормалізовані таблиці та хитрі індекси, щось виноситься в nosql, щось в elastic search, а шось взагалі в щось схоже на annoy індекс чи in-memory структури.

    Як на мене, проектувати БД треба руками, писати dao класи теж (або генерити, а потім правити). Mapper між ними треба генерити і потім НЕ правити (а краще і що б не читати)

    А після цього всього бажано ізолювати це все від решти проекту якимось шаром абстракції, який можна за-mock-ати.

  • Как использовать Hibernate: основные проблемы и их решения

    Є декілька різних позицій по цьому питанню.

    1. Proxy задає життєвий цикл, здавалося б data об’єкта.

    У вашій логіці є одне протиріччя. З однієї сторони, ви будуєте класи OOP-way — ціль достойна. Але з іншої, використовуєте для цього досить сильну магію.

    В магії, як такій, нічого поганого немає, але в цьому випадку, кінець-кінцем, доведеться працювати з proxy об’єктами, а не з чистими data класами. І це в багато чому множить на нуль всі старання (так як ви вже не можете з цим об’єктом працювати як з data, він прив’язаний до storage/session, управляється ним та без нього не існує).

    2. Ви натягуєте data об’єкт на базу.

    Ви згадали про DTO. І вірно зазначили, що DTO часто відрізняються. Більше того, є сенс також розрізняти DTO (структури в запитах/відповідях api), DAO(структури для роботи з storage) та data-класи (структури для роботи в пам’яті). В більшості випадків, як мінімум з початку розробки, всі ці три набори класів сутностей тупо ідентичні. І в усіх цих випадках є сенс НЕ плодити сутності і взяти, наприклад, DAO класи і використовувати їх всюди. Як тільки десь щось змінюється — це все рефакториться та сутність розділяється.

    Так ось, на вашому прикладі, перша модель — це для DAO, а друга — це для data. І мапити їх через ORM — це костиль, який спрацює лише в такому випадку як ви описали. Додайте сюди, скажем searchString в DAO (який генериться з інших полів не очевидним чином, щоб потім з нього пошук LIKE-ом робити). Та додайте в data-класі, замість Map items якусь специфічно оптимізовану колекцію (уявімо, для прикладу, що Item не товар, а щось, що має якісь координати, і колекція — не Map, а якийсь geo індекс). Також в data можна додати пару atomic примітивів та lock-ів для роботи в synchrinized. А тепер зліпіть ці дві сутності в одну і зробіть марінг в базу.

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

    3. Базу даних потрібно «поважати» ... вона все-таки зберігає для вас ваші дані :)

    БД — не проста штука. І коли даних багато і складних, треба вирішити як з ними швидко працювати. І тут логіка починає тягнутися: в sql створюються денормалізовані таблиці та хитрі індекси, щось виноситься в nosql, щось в elastic search, а шось взагалі в щось схоже на annoy індекс чи in-memory структури.

    Hibernate-like ORM ж кажуть: «та забийте, ми все зробимо ... ви тільки гляньте що ми можем і розберіться», але в результаті, по факту, там закрито дуже мало тих методів, що можна використати для оптимізації роботи з БД і зроблено це так, що ще можна пальці повідстрілювати.

    4. В коментарях згадувався аудит...

    Я не працював з аудитом в Hibernate, але з того, що доводилось робити, хуки на базу — було б дуже грубим рішенням.

    В тих проектах, де ми робили аудит-логи, ці логи були на рівні чуть вище бази. Наприклад лог міг виглядати як: «[req:12355][user:45][ip:127.0.0.1][agent:android/chrome] Авторизація Петро Петро Петрович»,
    а не " Петро Петро Петрович lastLogin changed from XXX to YYY«.

    5. Неочевдний життєвий цикл

    Можливо, це все Hibernate і вміє, але є сенс звертати увагу на наступне.

    Сутності бувають різні. Крім класичних строго транзакційних (користувач змінив name чи створив замовлення), ще є словники (які вигідно записати в map в пам’ять і оновлювати кожні 10хв або по зовнішньому trigger-у), логи (append-only, можна писати bulk-ом), статистика (можна накопичувати і писати агреговані зміни раз в хвилину)

    Кожен з цих випадків працює по різному і, в цілому, ломає роботу з одним «графом» об’єктів.

    Окремо є сенс згадати транзакційність...
    Я не знаю як в кого, але в нас з нею є вже традиційні особливості. І поки не видно яка може бути альтернатива retry-циклу з ідемпотентним try/catch-ем з явним контролем того які запити і в якому пооядку робляться.

    А то буває тут kill −9 прилітає (чи щось типу пропало з’єднання до бази, якийсь lock wait exception чи disk is full, або, взагалі dead lock) а потім шукай що там де не так.

    ------
    В цілому, для ясності, я не є великий противник ORM. ORM — це часто зручно. Але від ORM я чекаю простий і швидкий mapper на data клас, простий crud api, зручний api для raw sql, optional query builder та утиліти для крайніх випадків (mass select/insert/update, управління транзакціями, тощо).

    Робота ж з DDL, каскадний select/update/delete, детектор змін в об’єктах, кеш об’єктів з БД, автоматичні join-и, автоматична підтримка купи БД одночасно, та своя мова запитів — це все тільки ускладнює роботу.

    Підтримали: Andrii Prypin, Psyh 2409
  • Когда уже отменят 8 марта? Хуже рабочего дня (((

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

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

    Короч, як кажуть celebrate diversity:) Інакше це diversity, в гонитві за своїми правами почне обмежувати права інших, але цього разу зі значним перегином на свою користь.

    Підтримав: Locky
  • Советы ментору: как помочь новичку преодолеть страхи и успешно интегрировать его в команду

    «Технічна», як ви кажете, частина часто перетинається з «психологічною».

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

  • Советы ментору: как помочь новичку преодолеть страхи и успешно интегрировать его в команду

    Страхи (боятися зробити помилку, боятися «налякати» новачка), комплекси (боятисья задати питання чи проявити некомпетентність) та некомунікабельність (фейли при донесенні та сприйнятті критики) як ментора так і новачка — то одна сторона медалі.

    Інша сторона медалі — це те, що на менторство потрібен час (виділення задач, пояснення, дискусії ... тощо). І часто в перші місяці роботи цього часу треба десь до 25% від усього робочого. Тобто, повішайте на людину 3 джуна і погодьтесь, що роботою такий ментор буде займатися 1-2 години в десь.

  • Как побороть в себе синдром самозванца?

    Та ну ... 4роки*365*5/7*8=8342 робочих годин.... ви навіть 10к годин не пропрацювали :)

    А взагалі, не партесь, я вже більше 10 років в сфері, 5+ вже працюю з джавою, при цьому практично постійно виникають задачі, які бачу вперше і хз як до них підходити.... ну і ще НЕ доводилось писати жодної стрічки під Spring та Hibernate (знання яких є в 90% вакансій на джуна).

    Так що тут краще змиритися... поки вивчеться щось одне, поряд появиться ще «2 нових js фреймворка».

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

  • Из Java Dev в Information security, есть ли смысл?

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

    Якщо говорити про окрему професію, то я бачив два напрямки. Перший — це penetration tester — по суті, білий хакер, який робить аудит систем і намагається їх поламати. Другий — це «контррозвідник», в обов’язки якого, в тому числі, входить пошук в компанії «поганих людей», їх «допит», організація політк безпеки в компанії(доступ по карткам, просування «супер-захищених-vpn» та «щоб бекап сховище було на кожному континенті в бункерах»).

  • 12 ошибок при построении архитектуры ПО

    Ну ... з вікіпедії принцип каже: if S is a subtype of T, then objects of type T may be replaced with objects of type S.

    Тобто до використання switch це немає відношення.

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

    если у Вас получается case, то подумайте про LSP с подклассами

    Якщо у вас по природі сутність є скінченним автоматом, то що тут зробиш? Switch (або краще if/else... хехе) — наше все. Ну ... або є шаблон state, коли обробка стану завелика для одного switch-а. Наврядчи хтось скаже, що зробити коректне наслідування для блоку класів зі шаблону state буде легше, ніж для одного класу зі switch-ом.

    Доречі ... для тих, хто занадто полюбляє мудрити в архітектурі, є дуже гарний спосіб трохи «освіжити погляд»: спробувати навчитися програмувати на C (без плюсів) для мікроконтроллерів чи для ядра якоїсь системи. Після того як вдається вникнути в підходи, які працюють там, деякі архітектурні речі вже сприймаються по іншому.

  • 12 ошибок при построении архитектуры ПО

    Щодо DTO та інших моделей .... ви, звісно, праві, що їх є сенс розділяти .... в сферичному проекті у вакуумі :)

    Зі свого досвіду можу сказати, що не варто множити різних моделей дуже багато і є сенс використовувати те ж DTO до тієї міри, поки в нього не треба вносити суттєвих змін (якщо роль DTO — це data class, а не mega-orm-super-smart-proxy-object). В такому випадку на інших шарах логіки, нових моделей стає значно менше, ніж в БД.

    Додам, що всупереч сказаному, в одному з андроїд додатку, який ми робили, були два повністю окремих паралельних набори моделей: для роботи з серверним API та для локальної БД. В теорії, потрібен був ще третій: для представлення сутностей в «самому додатку», але в 90% таких випадків з цим чудово впорались моделі локальної БД.

  • 12 ошибок при построении архитектуры ПО

    Хоч і в статті є до чого придертися (наприклад, коментар щодо Liskov substitution та switch не зовсім коректний). Але в цілому досить непогано описано досвід.

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

  • Три основные проблемы умных домов и как их можно решить

    В цілому, вірно. Щоб замінити звичайну розетку люди зараз теж викликають електрика.

    Аналогічно і для «розумних» розеток будуть свої «електрики».

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

  • Три основные проблемы умных домов и как их можно решить

    Посилання?

  • Три основные проблемы умных домов и как их можно решить

    Кожен бачить свої проблеми... як на мене основною проблемою є те, що кожен виробник ставить на меті зробити 100% закінчений продукт: щоб принести з магазину, розпакувати, налаштувати та користуватися. Це НЕ вірно. Треба робити конструктор.

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

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

    Поки, я бачив близьку до цього філософію лише в sonoff. Решта все — не придатне.

    Розумний будинок — це коли всі 100500 пристроїв здатні працювати узгоджено і з одним додатком, а не коли кожен окремо і з своїм wifi-єм і андроїдом.

  • Java дайджест #41: итоги 2018-го и предсказания на 2019-й

    Спочатку самописний registry на hashmap. Не дуже модно, але працює залізно і ніяких xml. Зараз майже всюди перейшли на dagger ... він в compile time все робить — задоволені.

    Колись ще дивились на guice, але він, як і spring сприймається як важкий reflection-залежний монстр.

    Підтримав: Alexandr Sova
  • Java дайджест #41: итоги 2018-го и предсказания на 2019-й

    уместно ли будет включать больше архитектурных статей, чего-то про ДевОпс, БД и в общем статей про software engineering?

    В цілому, звісно, цікаво, але якщо цей дайджест про java, все-таки є сенс тримати тематику пов’язану саме з цим. Про DevOps, наче, був окремий дайджест.

  • Java дайджест #41: итоги 2018-го и предсказания на 2019-й

    Та, насправді, не особливо так і пов’язано.
    Просто, інколи, важко почути «java», щоб не почути «spring» (якщо мова не про android).

    Не сприймайте критично, але, наприклад, в розділі «Что-то вроде новостей», коли бачиш Spring Boot поряд з Gradle та Idea ... це виглядає як «знайдіть зайве». Тим більше, що нічого революційного там в тій версії майже немає ... пару фіч та java 11.

    Якщо вже так, то ... хм ... чому б там не згадати, про, наприклад «Dagger 2.21» — теж нещодавно вийшов, чи про ще 100500 популярних бібліотек, які час від часу оновлюються? (останнє, доречі, тягне на окрему рубрику в дайджесті :) )

← Сtrl 1... 45678...24 Ctrl →