Категорія: Subjective

 

Покращуючи CFScript

Шон Корфілд розповів про те, як відбувається еволюція CFScript. Він навів приклад того, як було втілено функції в різних серверах застосунків та роль CFML Advisory Commitee. Ми вже колись згадували про цю тему.

Що цікаво, я вже довгий час сповідую синтаксис, аналогічний до наведеного прикладу ColdBox: класичне визначення cffunction+cfargument, а тіло на cfscript.

Треба відмітити, що до широкого використання нового синтаксису ще далеченько, аж поки CF9 та Railo не займуть достатньо велику частину ринку. До того часу доведеться писати сумісний з CF8 код, щоб забезпечити собі спокійний тил.

Автор: Сергій Галашин | Опубліковано: 30.12.2009 о 09:54 | Категорії: CFML - CFScript - ColdFusion 8 - ColdFusion 9 - Railo - Subjective -

 

Дискусія: чому CFML, а не Java?

Нещодавно Шон Корфілд (Sean Corfield) опублікував невеличку замітку, в якій критично висловився щодо компанії, котра витратила три роки (!) на переписування сайту з CFML на Java.

Обговорення тої самої новини на TechCrunch вилилося в значну дискусію за участі великої кількості авторитетних членів спільноти (навіть Бен Форта завітав!), частина якої перекинулася й на коментарі до посту Шона.

Зокрема, в них відмітився оборонець ідеї переписування (можливо, учасник) Девід Теннерсін (David Tannersyn), котрий викликав нову хвилю обговорення, що призвело до написання Шоном нової ґрунтовної публікації Why CFML? Why not Java?, котра має на меті розставити крапки над "і" в цій дискусії.

Рекомендую до ознайомлення, все доволі цікаво.

Автор: Сергій Галашин | Опубліковано: 13.12.2009 о 20:15 | Категорії: Blogs - CFML - Community - Discussions - Java - Jobs - Subjective -

 

FuseNG -- ненароджене дитя

Незважаючи на певний оптимізм, проявлений спільнотою кілька місяців тому з приводу спроби переродження Fusebox, породжений заявою головного розробника останнього Адама Хаскеля про початок роботи над FuseNG, мріям не було суджено здійснитися. Суть подій була в тому, що компанія Teratech гальмувала розвиток Fusebox, через що фреймворк поступово відставав від розвитку подій в галузі, тому Адам зробив спробу витворити гілку проекту, повністю підтримувану спільнотою, аби надати проектові другий шанс.

На жаль, виявилися правими скептики, що не вірили в успіх цієї ініціативи.

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

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

Шкода, він досі є моїм першим та улюбленим фреймворком.

 

Автор: Сергій Галашин | Опубліковано: 12.11.2009 о 23:02 | Категорії: Blogs - Community - Fusebox - Subjective -

 

Railo Tips: типи аргументів, відносні шляхи та згенеровані ключі

Працюючи над портуванням проекту під Railo стикаюся з різними особливостями роботи двигуна, котрі варто пам'ятати щоб не наступати на ці граблі надалі.

 

Спершу виникла проблема з nullable атрибутами в Transfer ORM. В моєму випадку NULL для поля з типом DATE зручно було використовувати для дати завершення строку дії рахунку. Для цього дефініція виглядала наступним чином:

<property name="expirationDate" type="date" column="exp_date" nullable="true" />

Тоді методи object.setExpirationDateNull() / object.getExpirationDateIsNull() давали потрібний результат.

Transfer зберігає NULL-дати в своєму особливому форматі (фактично, дата в далекому минулому), але при витягання NULL з бази все одно ColdFusion конвертував його в порожій рядок. Цей факт і став фатальним при передачі витягнутого значення сеттерові setExpirationDate(<date>).

Railo, на відміну від CF8, не бажає сприймати порожній рядок як коректну дату при передачі його аргументом функції.

Внаслідок цього довелося відмовитися від nullable атрибутів та трішки переробити спосіб відслідковування дат завершення строку.

 

UPDATE

Насправді, це виявилося проблемою коду, що взаємодіяв з Transfer. Бо несприйняття порожнього рядку є нормальним явищем для будь-якого CFML парсера.

 

Іншою проблемою стало використання наступного методу ініціалізації об'єкта:

variables.logBean = CreateObject("component", "model/LogBean").init( arguments.pageid, arguments.userid );

Такий відносний шлях не спрацював в Railo.

На щастя, динамічні мапінги в ньому працюють, тому я використав вже існуючий і переробив код наступним чином:

variables.logBean = CreateObject("component", "components.core.model.LogBean").init( arguments.pageid, arguments.userid );

 

Наостанок мене трохи розчарував той факт, що Railo не дістає останній доданий ключ в result запиту, зокрема для MySQL там не встановлюється GENERATED_KEY взагалі (додано 30.11.2009 -- виправлено!). В якості тимчасового рішення використав наступний спосіб:

<cflock name="#this.lockName#" type="exclusive" timeout="5">

    <!--- push bean into the db ---->
    <cfquery datasource="#variables.dsn#" name="qAddLogEvent" result="qResult">
        INSERT INTO #variables.tableLogCurrent#
            (id_page, id_user, log_type, log_message, log_detail, remote_ip, moment)
        VALUES
            (
             <cfqueryparam cfsqltype="cf_sql_integer" value="#logBean.getPageId()#" />,
             <cfqueryparam cfsqltype="cf_sql_integer" value="#logBean.getUserId()#" />,
             <cfqueryparam cfsqltype="cf_sql_char" value="#logBean.getLogType()#" />,
             <cfqueryparam cfsqltype="cf_sql_char" value="#logBean.getLogMessage()#" />,
             <cfqueryparam cfsqltype="cf_sql_char" value="#logBean.getLogDetail()#" />,
             <cfqueryparam cfsqltype="cf_sql_char" value="#logBean.getRemoteIp()#" />,
             <cfqueryparam cfsqltype="cf_sql_timestamp" value="#logBean.getMoment()#" />
            )
    </cfquery>

    <!--- this is a workaround for the engines not supporting GENERATED_KEY --->
    <cfif NOT StructKeyExists(qResult, "GENERATED_KEY")>

         <cfquery datasource="#variables.dsn#" name="qResult">
             SELECT LAST_INSERT_ID() AS GENERATED_KEY
         </cfquery>

    </cfif>

</cflock>

Хорошою ж новиною є те, що цей прикрий факт можна змінити. Для цього треба проголосувати у відповідному запитові Uservoice. Знаючи лояльність розробників я вірю, що потрібні зміни будуть доволі скоро.

 

Автор: Сергій Галашин | Опубліковано: 27.09.2009 о 18:03 | Категорії: MySQL - ORM - Railo - Subjective - Tips - Transfer -

 

Про (CF)Eclipse, ColdFusion Builder та IDE

Спочатку Бен Форта, а пізніше й Шон Корфілд розродилися обширними розповідями про IDE взагалі та IDE для ColdFusion зокрема.

Чтиво вийшло доволі цікавим, але обидві замітки підводяться під однакові висновки: CFEclipse житиме, але CF Builder will rock ColdFusion-світ.

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

Але, як завжди є нюанси. Наприклад факт, що Adobe поки навіть не планує випускати Builder під Linux. Також незрозумілою залишається цінова політика. Якщо він коштуватиме як Flex Builder, то особисто мені така пропозиція навряд чи буде цікавою. Зокрема з тієї причини, що CF-спільнота активних розробників не така вже й велика, щоб сприймати її як джерело доходу, замість того щоб стимулювати її ріст, що є доволі принциповим питанням.

 

Винесу з коментарів першого посту пояснення Бена про перспективи CFB на Linux та PPC Mac:

...platform support is a $'s issue plain and simple. Right now the vast majority of ColdFusion developers do their work on Windows and Intel Mac, and so those are supported. (FWIW, this is in contrast to ColdFusion itself which is deployed on Windows and Linux mostly, and rarely on Mac). If there are enough requests from developers for a Linux version, and by that I mean enough to cost justify the work (yes, there is additional cost associated with any additional platform) then we'll do it, and if not then not. Thus far, there has been significant demand for Linux as a ColdFusion server platform, but far less for it as a development platform. But we'll keep watching it to see if things change.

 

 

Автор: Сергій Галашин | Опубліковано: 29.07.2009 о 07:25 | Категорії: Adobe - CFEclipse - ColdFusion Builder - Discussions - Subjective -

 

Найміть Community Expert працювати

Цікаве питання про роботу в галузі було підняте в пості Шона Корфілда (Sean Corfield).

Крім обговорення загальної ситуації та порад було визначено кілька причин того, чому компанії побоюються пропонувати роботу добре відомим учасникам спільноти (Community Expert в термінах Adobe).

Зокрема було сказано, що вони дуже багато часу приділяють спільноті :)

Мається на увазі, що вони багато виступають на конференціях, пишуть в блоґи/twitter, беруть участь у відкритих проектах і тому не мають часу працювати. Звісно, малося на увазі працювати повний робочий день, як це роблять "звичайні" програмісти.

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

І все це замість того, щоб просто радісно ковбасити код разом з колегами-програмістами ("work happily with their peers and code like a demon").

 

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

На цій оптимістичній ноті започатковуємо нову категорію Subjective.

 

Автор: Сергій Галашин | Опубліковано: 02.07.2009 о 06:43 | Категорії: Blogs - Jobs - Subjective -