Недавно я с удивлением обнаружил, что, оказывается, толковых туториалов по Oracle Application Express (он же APEX, он же апекс, но не путать с языком apex, который используется в Salesforce) в природе не существует.

Это не самая распространенная технология, конечно, но, тем не менее, довольно востребованная. Есть десятки блогов об апексе (англоязычные, в основном), пара тысяч вопросов на Stackoveflow, специальный раздел по апексу на официальных форумах оракла, сам апекс существует уже 15 лет и все время развивается. Я был уверен, что и хороших туториалов полно. Но нет!

Мне тут же пришла в голову гениальная мысль восполнить этот пробел.

Оглавление

Почему существующие туториалы — плохие
Вводная информация
Обзор IDE
    App builder
        Страница приложения
        Application properties
        Shared Components
        Page Designer
    SQL Workshop
        Object Browser
        SQL Commands

Проблема верификации опыта

"Reduce the complexity of life by eliminating the needless wants of life, and the labors of life reduce themselves." - Edwin Way Teale

Примерно два года назад в декабре 2020 года я ушел с работы и решил попробовать пожить на доход с капитала следуя "правилу 4%". Как-то незаметно прошло два года и у меня появилось желание подвести какие-то промежуточные итоги. Далее я в не очень структурированном виде изложу некоторые промежуточные итоги после первых двух лет "жизни на доход с капитала" или "ранней пенсии".

Код Хабра день за днём впитывает в себя время, мысли и чаяния многих людей. Этому коду более 10 лет: он оброс множеством знаний, в том числе и тайных. Места c bus factor = 1 — не эка невидаль, а вполне конкретные люди с ответами на часто задаваемые вопросы.

Меня зовут Антон Каракулов, я тимлид команды бэкенд-разработки Хабра. Хабр стартовал в 2006 году, и за всё время здесь поработало, наверное, команд пять. Мне посчастливилось быть в двух из них, забегал в третью.

Эту статью я написал в рамках проекта Хабра «IT-гид», где разработчики рассказывают про свои направления. Постарался собрать в ней главные практические выводы и интересные грабли, которые нам попадались в процессе превращения старого хабракода в чистый, масштабируемый и понятный для всех — то есть человекочитаемый.

Все события утрированы, а совпадения — беспочвенны.

С 29 декабря 2022 до 24 февраля 2023 Хабр вместе с #CloudMTS запускает сезон Kubernetes — конкурс технических статей о K8s, оркестрации и управлении контейнерами. Это третий сезон Хабра: летом и осенью мы уже неслабо продвинули пачку крутейших хардкорных текстов о Java и Data Mining. Теперь пришла пора разобрать по косточкам Kubernetes и относящиеся к нему DevOps-практики.

UPD. Сезон закончился, итоги можно посмотреть в этой статье.

Почему ИТ специалисты на самом деле не любят выполнять тестовые задания? Почему меньше откликов на вакансии без указания зарплаты? Простые ответы на сложные вопросы.

Когда ручного тестировщика впервые просишь проверить метод REST API, того охватывает паника: «Как это делать? Я вообще почти ничего не знаю про API. Что делать? Как это тестировать?»

Спокойно. Без паники =) Я уже рассказывала на простом языке, что такое API. А сегодня я расскажу о том, как его тестировать. На самом деле почти также, как GUI: в первую очередь это тест-дизайн и придумывание проверок, а потом уже всякие API-штучки. Но и про них не стоит забывать.

Я дам вам чек-лист, к которому вы сможете обращаться потом — «так, это проверил, и это, и это. А вот это забыл, пойду посмотрю!». А потом мы обсудим каждый пункт — зачем это проверять и как.

После теории будет практика! Для неё возьмем метод doRegister системы Users — он находится в открытом доступе, можете дергать по ходу чтения и проверять =) 

Что только нам не обещали с появлением Big Data. Мы будем прогнозировать продуктовый спрос и вспышки болезни, научим нейросети рисовать картины и сочинять романы, от которых плакал бы сам Достоевский (воссозданный теми же нейросетями по дневникам, портретам и рассказам современников). Что-то из этого уже в каком-то виде увидело свет — и это круто. Но большинству компаний это неинтересно и не нужно. Вместо суперсовременной архитектуры с плюшками-свистелками мы ищем аналоги наших старых хранилищ, но быстрее, дешевле и полегче в настройке. И это наглядно видно на примере историй Databricks и Snowflake.

После небольшой статьи про особенности при работе с кэшем (https://habr.com/ru/post/687146/) мне в личку прилетело несколько замечаний про работу спинлоков и приглашение на собес от пчелайнов, приятно, что технические статьи читают не только технари... лирика. Возвращаясь к обсуждению спинлоков, вышедших за рамки хабра, если это вызвало интерес, почему бы не написать про работу с этими примитивами синхронизации. Тема действительно интересная, да и разработчики придумали более десятка разновидностей спинлоков под разные вкусы и нужды. Все опять будет с тестами и примерами работы. @tbl Линус действительно прав, в юзерспейсе спинлоки "зло злющее", но как обычно есть нюансы...

Я работаю удалёнщиком с 2019 года, когда о предстоящем пандемийном безумии ещё никто не подозревал. «Ха» - скажете Вы, глядя свысока событий, произошедших совсем недавно. Да, тогдашние мои проблемы не идут ни в какое сравнение с нынешней ситуацией, но именно тогда всё для меня и началось.

Для многих из нас смена работы и предстоящие собеседования повергают в небольшую панику. Иногда от самих интервью хочется навсегда бросить это IT. А я прошёл собеседований несколько десятков, если не сотен, и готов поделиться своим бесценным опытом.

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

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

 P.P.S. Очень много текста внутри.