понедельник, 4 августа 2014 г.

FND_STANDARD_DATE

Если мы хотим передавать параметр даты из OEBS при вызове concurrent, то
1. Объявляет переменную типа FND_STANDARD_DATE или FND_STANDARD_DATETIME
2. В значении по-умолчанию можно указать такую штуку:

-- Формат даты и даты-времени зависит от настроек в OEBS select fnd_date.date_to_displaydate(SYSDATE) from dual; -- 04-АВГ-2014 select fnd_date.date_to_displaydt(SYSDATE) from dual; -- 04-АВГ-2014 15:28:28 select fnd_date.date_to_chardate(SYSDATE) from dual; -- 04-АВГ-2014 select fnd_date.date_to_chardt(SYSDATE) from dual; -- 04-АВГ-2014 15:28:28 функции ...date даты без времени, функции ...dt дата со временем 3. В pl/sql-процедуре переменная типа varchar2, которая преобразуется к дате с помощью функции PROCEDURE p( ... , p_dt VARCHAR2 ... ) IS l_dt DATE; BEGIN l_dt := fnd_date.canonical_to_date(p_dt); Каким бы мы способом не отображали дату в значениях по умолчанию, передеается она в canonical

пятница, 1 августа 2014 г.

Git кишками наружу

По-моему просто отличный комментарий про git с хабра.

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

И да, я постоянно боюсь, что я что-нибудь сломаю. Потому что с git я постоянно что-нибудь ломаю. Шаг вправо/шаг влево от типового workflow «add-commit-push», и все, капец. Сиди гугли, консультируйся на git@freenode и бей в бубен. Авось починишь.

Чаще, чем хотелось бы, оказывался в ситуации, когда переделать работу заново было проще, чем восстанавливать покалеченное состояние репозитория.

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

А все потому, что git сделан кишками наружу. Если провести аналогию со стиральной машиной, то у git на переднюю панель выведены не кнопки «деликатная стирка», «отжим» и т. п., а «нагреть спираль», «подать воду», «раскрутить барабан» и далее в таком духе. И любое неверное действие заставляет вас горько жалеть, что вы — домохозяйка. Включил нагрев, забыв подать воду, — сжег одежду. Открыл крышку, забыв слить воду, — затопил соседей.

Или представьте, что git — это автомобиль. В случае с любым другим автомобилем, вы можете быть высокопрофессиональным водителем и при этом не иметь никакого представления, что у автомобиля под капотом. Но только не с git! C git вы должны быть матерым автослесарем, способным с завязанными глазами перебрать карбюратор, чтобы водить эту машину. В противном случае недостаточное знание git приведет к тому, что во время езды он вас катапультирует на ровном месте — но ведь любой уважающий себя автослесарь знает, что нельзя втыкать зарядку в прикуриватель в то мгновение, когда «стреляют» свечи зажигания.

Сейчас набегут гуру программироавния и объяснят, что я лох и не умею пользоваться инструментом (ну и карму сольют, куда без этого). Так вот, отвечу, что во всем мире вэб-разработки нет другой такой программы, как git. Все остальные утилиты нормальные (с другими VCS не сравниваю, опыта нет). Из неадекватных инструментов можно вспомнить разве что vi, который во времена, когда в мобильниках не было интернета, не оставил мне, оздаченному школьнику, вариантов, кроме как перезагрузить комп. Но vi по сравнению с git, как говорится, курит в сторонке.

Спасибо-пожалуйста. 
Совершенно точно передана мысль про то, что не add-commit-push, то смертушка. Пока не попались утилиты (хотя особо и не искал), в которых можно было бы удобно сделать тоже, что так удобно делалоь в Tortoise