| > Gives more than one object an opportunity | |
| > to handle a request by linking receiving objects together. | |
| //Handler | |
| public interface EmailHandler | |
| { | |
| //reference to the next handler in the chain | |
| public void setNext(EmailHandler handler); | |
I'm going to open a cycle of small gist-posts - clojure one-filers - with implementations in clojure
some ideas & API's from another realms, which occupy there usually a whole library,
but in clojure could be just curled into project.
In this example we implement half of Rails form builder and simple_form library - nifty helpers for html forms:
Language files code
-----------------------------
Java: 167 39K
Clojure: 43 16K
SUM: 216 55K
-----------------------------
Scala: 1282 147K
Java: 88 9K
SUM: 1401 163K
| @prefix : <http://hl7/org/fhir/DiagnosticReport#> . | |
| @prefix fhir: <http://hl7/org/fhir/> . | |
| @prefix Narrative: <http://hl7/org/fhir/Narrative#> . | |
| @prefix Observation: <http://hl7/org/fhir/Observation#> . | |
| @prefix Quantity: <http://hl7/org/fhir/Quantity#> . | |
| @prefix Resource: <http://hl7/org/fhir/Resource#> . | |
| @prefix Reference: <http://hl7/org/fhir/Reference#> . | |
| @prefix Range: <http://hl7/org/fhir/Range#> . | |
| @prefix Codeable: <http://hl7/org/fhir/Codeable#> . | |
| @prefix Coding: <http://hl7/org/fhir/Coding#> . |
###Package Managers
Для любой потенциально полезной библиотеки, если она действительно полезна, наступает момент, когда хочется ее использовать чуть ли не в каждом проекте. Резонно возникает вопрос: "Как быстро подключить эту библиотеку в другом проекте?" А если другой проект находится на другой машине? А если проектов десяток? Об этом умные люди задумывались уже давно и нашли решение в создании системы управления пакетами. Существует множество таких систем для любых языков программирования: Bundler, npm, Bower и так далее.
Системы управления пакетами прекрасно решают вопрос быстрого подключения библиотеки. То есть, решают проблему со стороны конечного пользователя - клиента. Но дают ли они вспомогательные средства для другой стороны - автора библиотеки?
JSX Pro & Cons:
Pro:
Cons:
Concepts-Techniques-Models-Computer-Programming CMT это известная книжка CMT, за которой слава закрепилась не хуже чем у SICP
это из этой книжки классификация различных парадигм Если присмотришься, то увидишь, что Oz поддерживает большинство вариаций (с этой целью его и конструировали, чтобы можно было наглядно продемонстрировать различные подходы в одном языке)
FHIR include & revinclude behavior is non-DRY and sometimes confusing.
This is informal proposal of alternative for (rev)include - _with parameter - simple (graphql like) DSL to describe nested includes:
Encounter?_with=patient
=> Encounter?_include=Encounter:patient
Encounter?_with=patient{Patient}
In this talk, I want to share my experience gained during the development of frontend applications in several programming languages.
I think it's not a secret for anybody that developing large JavaScript applications is not so easy as it seems at first glance. We all want something simpler and more reliable. Therefore, many developers and even entire companies switch to different, compiled in JavaScript, programming languages. The bulk of such transitions is accounted for TypeScript and flow, and often, developers faced with more problems than they were before.
I wasn't the exception. Moving to a new project, I started using TypeScript and was disappointed. Luckily in my next project I used ClojureScript and it was like everything is illuminated!