scriptorium 0.0.3 → 0.7.2

data/doc/imported/0007-phoenix-isnt-rails/source.lt3

@@ -0,0 +1,87 @@
+.h1 Phoenix isn't Rails
+
+.set post.num = 0007
+.set post.slug = phoenix-isnt-rails
+.set post.date = 2015-07-27
+.set post.title = Phoenix isn't Rails
+.set post.tags = 
+.set post.views = computing
+.set post.published = yes
+.set post.deployed = no
+
+I don't know Elixir very well at all. But I've started to learn Phoenix now. The
+first thing to know: Phoenix is not Ruby on Rails (nor is it "Elixir on Rails").
+I began my learning experience by dutifully crunching through the tutorial and
+making my share (at least) of newbie mistakes. (Disclaimer: I'm not a web guy. I 
+don't natively "think" in those terms and perhaps never will.)
+
+At some point in the hello-world example, I stopped and did a count of the files
+under my tree. It will become clear in a moment why this was a little naive and 
+careless.
+
+At any rate, I think find . | wc -lreported 11,648 files to me. I found this
+a bit confusing and puzzling, and I didn't think it through.
+
+I chatted with Chris McCord and another guy I don't think I've met. This is a summary:
+
+hal_9000: chrismccord: I have a question about the philosophy/design 
+              of phoenix - if you have time/inclination and the answer is not too involved
+
+chrismccord: hal_9000: shoot
+
+hal_9000: first of all, i’m not a web guy - i’ve played with rails and several 
+              other things - wrote a few small apps.  One thing that appealed to me 
+              about Sinatra was how “lightweight” it was compared to Rails — you can 
+              write a primitive Sinatra app in a single file.
+    hal_9000: i “sort of” expected that Phoenix might be that way — but a find piped 
+              to wc showed me that a hello-world app has more than 11,000 files in it. 
+              why in general is that?
+
+chrismccord: hal_9000: remove the node_modules folder and re-run ws
+    chrismccord: it's all nodejs for the asset building
+    chrismccord: hal_9000: we are lightweight. It's a misconception I have to keep correcting. 
+                 We are much closer to sinatra than rails
+
+hal_9000: hmm, i don’t even know nodejs of course
+    hal_9000: chrismccord: thanks, i had a feeling i was missing something for sure
+
+chrismccord: hal_9000: you could write an app in a single file, but no-one does that, 
+                 because we don't write production software in a single file
+    chrismccord: hal_9000: It is also worth mentioning there is also nothing global in 
+                 phoenix. We are not a monolith like rails
+
+jeregrine: hal_9000: something to keep in mind here is that phoenix assumes you are 
+               writing production software. Eventually you will need to touch every file, otherwise 
+               it wouldn't generate the file
+
+hal_9000: chrismccord: ok, thanks, i will look more closely. i’m impressed with what i see
+
+jeregrine: hal_9000: if you are like me and have used sinatra for production software you 
+               probably discovered you ended up writing a slightly smaller version of rails
+
+hal_9000: jeregrine: that makes perfect sense
+
+jeregrine: hal_9000: if you only need a single route/api call, and are certain it will never grow, 
+               you could VERY easily get away with just plug and it's router
+    jeregrine: hal_9000: http://hexdocs.pm/plug/Plug.Router.html for reference.
+
+hal_9000: chrismccord: i grasp it now, sorry for the noise
+
+jeregrine: hal_9000: lemme know if you have any questions, this is something we need to be better at 
+               communicating. We are not rails
+
+chrismccord: hal_9000: no worries. Sorry if my response was rash too. I just have to fight a lot of 
+                 "phoenix is bloated" comments because people assume it is given my Rails background and 
+                 the comparisons with rails
+
+hal_9000: chrismccord: no, your response was not rash at all
+
+So first of all: I didn't pay attention to what I was doing when I did my file count.
+
+But the real takeaway here is: Phoenix isn't bloated, and more importantly, Phoenix isn't Rails.
+The philosophy seems to be more "minimalistic" as I had hoped.
+
+And of course, we all know that Elixir isn't Ruby. I won't belabor that point.
+
+On the other hand, I do find (so far) that Plug is a lot like Rack. That's a good thing, because I
+always thought Rack was sheer genius. More on that as I learn.

data/doc/imported/0008-concerning-the-term-monkeypatching/metadata.txt

@@ -0,0 +1,7 @@
+    num  0008
+  title  Concerning the term "monkeypatching"
+   date  2015-08-10
+pubdate  2015-08-10
+  views  computing
+   tags  
+ pinned  

data/doc/imported/0008-concerning-the-term-monkeypatching/post.html

@@ -0,0 +1,129 @@
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="utf-8">
+  <title>Concerning the term "monkeypatching"</title>
+  <meta name="generator" content="Scriptorium Import">
+  <meta property="og:title" content="Concerning the term "monkeypatching"">
+  <meta property="og:locale" content="en_US">
+  <meta property="og:type" content="article">
+  <meta property="article:published_time" content="2015-08-10">
+</head>
+<body>
+  <article>
+    <header>
+      <h1>Concerning the term "monkeypatching"</h1>
+      <time datetime="2015-08-10">August 10, 2015</time>
+    </header>
+    
+    <div class="content">
+      <p>
+There have been many "dark days" in the Ruby community, some much darker than others.
+Guy Decoux died, _why the lucky stiff_ left us (without dying), Jim Weirich died. (Yes, I count
+actual deaths as the darkest moments of all.)
+
+<p>
+But I count another dark moment that many of you will not. When I had been using Ruby a
+little more than six years, in December 2005, the term "monkeypatching" was introduced
+into our circle.
+
+<p>
+It was a post by Drew Mills, quoting a blog from a Python person who apparently hated Ruby.
+I don't blame Drew. I don't suppose I "blame" anyone. But I regret that this slang has entered
+our culture.
+
+<p>
+The post Drew quoted was this:
+
+<p>
+<blockquote>
+  It's the second generation that's going to be less enthused,   that's going to stare in bafflement at these classes that   mysteriously spawn methods, and trying to figure out what's   going when there's an exception in dynamically generated   code. You can monkeypatch code in Python pretty easily, but we   look down on it enough that we call it "monkeypatching". In   Ruby they call it "opening a class" and think it's a cool   feature. I will assert: we are right, they are wrong.
+</blockquote>
+Before I go on to my main point, I'll make an observation that is arguably much more interesting.
+If you read again, it sounds like the Python person (Ian Bicking) was talking about dynamic method
+dispatch (the use or abuse of method_missing) rather than actual open classes.
+
+<p>
+Someone later in that thread decried the "ignorance" of Bicking with regard to this -- that he didn't
+even know enough Ruby to know the difference between dynamic dispatch and open classes. I
+wonder if the original pythonism meant something different? Since I never completed my Python
+studies, I can't comment.
+
+<p>
+At any rate: Back to my story.
+
+<p>
+I still recall the revulsion I felt, almost physical nausea, when I read this the first time. That's probably
+a somewhat extreme response on my part.
+
+<p>
+I regarded open classes as a programming technique that is potentially very powerful but easy to misuse.
+This sounds like a "good and yet bad" argument. But let me rephrase that sentence.
+
+<p>
+Open classes are a technique that is potentially very powerful <i>(and</i> therefore) easy to misuse. That is
+the point. Any tool that is powerful enough is prone to misuse by people who are unskilled.
+
+<p>
+The term "monkeypatching" is obviously a pejorative term. Upon seeing it, my first thought was, "I am
+not a monkey, and I am not 'patching' anything."
+
+<p>
+After all, that is the implication. The term implies that the developer is a monkey, and that the work he is
+doing is sloppy or shoddy. It is an insult both to the quality of the developer's work and to the developer
+himself.
+
+<p>
+So it bothered me because it was a pejorative and it was insulting to us as programmers. It was also
+(arguably) an insult to Ruby itself and therefore by extension an insult to Matz.
+
+<p>
+I dislike being clannish, though perhaps sometimes I am. After all, Ruby is not (supposed to be) anyone's
+religion or cultural heritage. It's only a programming language, and I think it's very much like Python. But it
+also bothered me that this neologism originated <i>outside</i> our community, in particular with the Python
+community.
+
+<p>
+Generalizations are always wrong. (Yes, that's a joke.) And stereotypes as such are at least useless if not
+actually hurtful. And yet I always heard about the arrogance and rudeness of Python programmers, and I
+occasionally saw real evidence of it. And though I dislike the word "nice" in general, I always found it interesting
+that Ruby coders were labeled as "nice" (as in the abbreviation MINASWAN, "Matz is nice, and so we are nice").
+
+<p>
+So when this usage was introduced, I felt rather as though someone had opened my front door and dumped a
+large piece of dog manure onto my carpet. What is worse, it has wormed its way into common usage in our
+community, even in documentation. A lot of this happened in the early days of Rails, when fate dumped a huge
+influx of newbies onto the Ruby community. Not to disparage the Rails people in general, but at the time this
+felt much the same as it did back when AOL (America Online) made its debut and dumped millions of (insert
+noun here) into the Internet and Usenet communities.
+
+<p>
+It's impossible to stop this usage now (like so many other usages in the English language having nothing to do
+with computing). But I still protest, and I still stand against it.
+
+<p>
+The term "monkeypatching" appears only once in more than 800 pages of <i>The Ruby Way</i>. It occurs when  I
+say I don't condone this term, and it won't be used further in the book.
+
+<p>
+As an aside: The "refinements" which exist in recent versions of Ruby make open classes stricter and safer. I'll blog
+about that later. But this isn't much of a technical post. It's just a reminiscence and a rant.
+
+<p>
+So basically I hate the term "monkeypatching." I am polite to people who say it to me (e.g., in asking a question), but
+secretly I want to just ignore them.
+
+<p>
+The last time I saw Jim Weirich, in New Orleans, he and I talked about this. He agreed it was a pejorative term,
+and it was a shame it had entered the common dialect, though there was really nothing to do about it. But being
+much more level-headed and good-natured than I am, he wasn't bothered much by it.
+
+<p>
+I really miss Jim, by the way. He was a truly brilliant developer and an amiable and wonderful person in general.
+If it would bring him back, I would gladly change the book's name to <i>The Art of Monkeypatching</i>.
+
+<p>
+    </div>
+  </article>
+</body>
+</html>

data/doc/imported/0008-concerning-the-term-monkeypatching/source.lt3

@@ -0,0 +1,92 @@
+.h1 Concerning the term "monkeypatching"
+
+.set post.num = 0008
+.set post.slug = concerning-the-term-monkeypatching
+.set post.date = 2015-08-10
+.set post.title = Concerning the term "monkeypatching"
+.set post.tags = 
+.set post.views = computing
+.set post.published = yes
+.set post.deployed = no
+
+There have been many "dark days" in the Ruby community, some much darker than others.
+Guy Decoux died, _why the lucky stiff_ left us (without dying), Jim Weirich died. (Yes, I count
+actual deaths as the darkest moments of all.)
+
+But I count another dark moment that many of you will not. When I had been using Ruby a
+little more than six years, in December 2005, the term "monkeypatching" was introduced
+into our circle.
+
+It was a post by Drew Mills, quoting a blog from a Python person who apparently hated Ruby.
+I don't blame Drew. I don't suppose I "blame" anyone. But I regret that this slang has entered
+our culture.
+
+The post Drew quoted was this:
+
+It's the second generation that's going to be less enthused,   that's going to stare in bafflement at these classes that   mysteriously spawn methods, and trying to figure out what's   going when there's an exception in dynamically generated   code. You can monkeypatch code in Python pretty easily, but we   look down on it enough that we call it "monkeypatching". In   Ruby they call it "opening a class" and think it's a cool   feature. I will assert: we are right, they are wrong.
+
+Before I go on to my main point, I'll make an observation that is arguably much more interesting.
+If you read again, it sounds like the Python person (Ian Bicking) was talking about dynamic method
+dispatch (the use or abuse of method_missing) rather than actual open classes.
+
+Someone later in that thread decried the "ignorance" of Bicking with regard to this -- that he didn't
+even know enough Ruby to know the difference between dynamic dispatch and open classes. I
+wonder if the original pythonism meant something different? Since I never completed my Python
+studies, I can't comment.
+
+At any rate: Back to my story.
+
+I still recall the revulsion I felt, almost physical nausea, when I read this the first time. That's probably
+a somewhat extreme response on my part.
+
+I regarded open classes as a programming technique that is potentially very powerful but easy to misuse.
+This sounds like a "good and yet bad" argument. But let me rephrase that sentence.
+
+Open classes are a technique that is potentially very powerful (and therefore) easy to misuse. That is
+the point. Any tool that is powerful enough is prone to misuse by people who are unskilled.
+
+The term "monkeypatching" is obviously a pejorative term. Upon seeing it, my first thought was, "I am
+not a monkey, and I am not 'patching' anything."
+
+After all, that is the implication. The term implies that the developer is a monkey, and that the work he is
+doing is sloppy or shoddy. It is an insult both to the quality of the developer's work and to the developer
+himself.
+
+So it bothered me because it was a pejorative and it was insulting to us as programmers. It was also
+(arguably) an insult to Ruby itself and therefore by extension an insult to Matz.
+
+I dislike being clannish, though perhaps sometimes I am. After all, Ruby is not (supposed to be) anyone's
+religion or cultural heritage. It's only a programming language, and I think it's very much like Python. But it
+also bothered me that this neologism originated outside our community, in particular with the Python
+community.
+
+Generalizations are always wrong. (Yes, that's a joke.) And stereotypes as such are at least useless if not
+actually hurtful. And yet I always heard about the arrogance and rudeness of Python programmers, and I
+occasionally saw real evidence of it. And though I dislike the word "nice" in general, I always found it interesting
+that Ruby coders were labeled as "nice" (as in the abbreviation MINASWAN, "Matz is nice, and so we are nice").
+
+So when this usage was introduced, I felt rather as though someone had opened my front door and dumped a
+large piece of dog manure onto my carpet. What is worse, it has wormed its way into common usage in our
+community, even in documentation. A lot of this happened in the early days of Rails, when fate dumped a huge
+influx of newbies onto the Ruby community. Not to disparage the Rails people in general, but at the time this
+felt much the same as it did back when AOL (America Online) made its debut and dumped millions of (insert
+noun here) into the Internet and Usenet communities.
+
+It's impossible to stop this usage now (like so many other usages in the English language having nothing to do
+with computing). But I still protest, and I still stand against it.
+
+The term "monkeypatching" appears only once in more than 800 pages of The Ruby Way. It occurs when  I
+say I don't condone this term, and it won't be used further in the book.
+
+As an aside: The "refinements" which exist in recent versions of Ruby make open classes stricter and safer. I'll blog
+about that later. But this isn't much of a technical post. It's just a reminiscence and a rant.
+
+So basically I hate the term "monkeypatching." I am polite to people who say it to me (e.g., in asking a question), but
+secretly I want to just ignore them.
+
+The last time I saw Jim Weirich, in New Orleans, he and I talked about this. He agreed it was a pejorative term,
+and it was a shame it had entered the common dialect, though there was really nothing to do about it. But being
+much more level-headed and good-natured than I am, he wasn't bothered much by it.
+
+I really miss Jim, by the way. He was a truly brilliant developer and an amiable and wonderful person in general.
+If it would bring him back, I would gladly change the book's name to The Art of Monkeypatching.

data/doc/imported/0009-announcement-coming-soon/metadata.txt

@@ -0,0 +1,7 @@
+    num  0009
+  title  Announcement coming soon...
+   date  2015-08-11
+pubdate  2015-08-11
+  views  computing
+   tags  
+ pinned  

data/doc/imported/0009-announcement-coming-soon/post.html

@@ -0,0 +1,33 @@
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="utf-8">
+  <title>Announcement coming soon...</title>
+  <meta name="generator" content="Scriptorium Import">
+  <meta property="og:title" content="Announcement coming soon...">
+  <meta property="og:locale" content="en_US">
+  <meta property="og:type" content="article">
+  <meta property="article:published_time" content="2015-08-11">
+</head>
+<body>
+  <article>
+    <header>
+      <h1>Announcement coming soon...</h1>
+      <time datetime="2015-08-11">August 11, 2015</time>
+    </header>
+    
+    <div class="content">
+      <p>
+Maybe this will stir your curiosity a little. I hope it does.
+I've started working on a project with someone else, and I 
+think it will be really worthwhile.
+This will be launched within 48 hours and announced at the
+Lone Star Ruby Conference in Austin, Texas (October 15).
+Maybe it will be leaked a little before then, too.
+
+<p>
+Sit tight 48 hours or so...
+    </div>
+  </article>
+</body>
+</html>

data/doc/imported/0009-announcement-coming-soon/source.lt3

@@ -0,0 +1,19 @@
+.h1 Announcement coming soon...
+
+.set post.num = 0009
+.set post.slug = announcement-coming-soon
+.set post.date = 2015-08-11
+.set post.title = Announcement coming soon...
+.set post.tags = 
+.set post.views = computing
+.set post.published = yes
+.set post.deployed = no
+
+Maybe this will stir your curiosity a little. I hope it does.
+I've started working on a project with someone else, and I 
+think it will be really worthwhile.
+This will be launched within 48 hours and announced at the
+Lone Star Ruby Conference in Austin, Texas (October 15).
+Maybe it will be leaked a little before then, too.
+
+Sit tight 48 hours or so...

data/doc/imported/0010-immutable-data-ditching-the-wax-tablet/metadata.txt

@@ -0,0 +1,7 @@
+    num  0010
+  title  Immutable data (ditching the wax tablet)
+   date  2015-08-25
+pubdate  2015-08-25
+  views  computing
+   tags  
+ pinned  

data/doc/imported/0010-immutable-data-ditching-the-wax-tablet/post.html

@@ -0,0 +1,175 @@
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="utf-8">
+  <title>Immutable data (ditching the wax tablet)</title>
+  <meta name="generator" content="Scriptorium Import">
+  <meta property="og:title" content="Immutable data (ditching the wax tablet)">
+  <meta property="og:locale" content="en_US">
+  <meta property="og:type" content="article">
+  <meta property="article:published_time" content="2015-08-25">
+</head>
+<body>
+  <article>
+    <header>
+      <h1>Immutable data (ditching the wax tablet)</h1>
+      <time datetime="2015-08-25">August 25, 2015</time>
+    </header>
+    
+    <div class="content">
+      <p>
+A couple of weeks ago, I went to Phoenix training prior to the Lone Star Ruby
+Conference in Austin. I was talking with Bruce Tate, and he shared with me 
+some thoughts about functional programming in general. 
+Obviously Bruce isn't responsible if I misquote him. My memory is faulty.
+
+<p>
+"Functional programming is the future," he told me, "and OOP is dying." 
+He pointed to the ever-increasing popularity of multi-core machines and the 
+increasing irrelevance of conserving memory.
+
+<p>
+He said that OOP was all about optimizing for memory usage, and that was 
+no longer such a big concern. I wasn't sure what he meant. I thought about it
+later, and decided I was probably missing some profound points. 
+
+<p>
+But at the same time, I thought I saw something with a clarity that I hadn't
+before. I have wrestled with the concepts of FP over the last year or two; as
+a procedural and OOP type, it hasn't always fit into my brain quickly or
+easily. 
+
+<p>
+At times it felt that I was taking a step backwards technologically, back into 
+procedural thinking. On the one hand, that isn't really true. On the other
+hand, I think we all know what backtracking is for. If you've ever gotten lost
+in a strange town, you know that sometimes you have to back up to a known
+point and try going off in a different direction. 
+
+<p>
+If you're interested, you could make some fine analogies here between human 
+technological advances and things like game theory and machine learning. It's
+hard to imagine navigating a maze or implementing a chess-playing program
+without the concept of backtracking. But that's not my point here.
+
+<p>
+One of the key concepts in functional programming, as I understand it, is that
+of immutable data. I have spent hours puzzling over this, because it hasn't 
+been immediately intuitive to me.
+
+<p>
+There was a quote I read once that the GOTO statement caused difficulties 
+because it left us with the question, "How did I get here?" And mutable data
+leaves us with the question, "How did I get to this state?" That made sense
+to me, at least a little.
+
+<p>
+It got me to thinking about a more remote time, when I taught programming 
+concepts to beginners (using BASIC). In an effort to explain how a program
+worked, I would run through an exercise on the whiteboard which I called 
+"playing computer." Variables were represented by little boxes which more or 
+less corresponded to memory locations. As I manually stepped through the execution
+of some simple program, I would erase and update the contents of these boxes.
+
+<p>
+It was nice and effective, but I sometimes did it another way. I expressed the
+same information in the form of a table, with variable names across the
+columns and time increasing down the rows. This made it clear not just what
+values the variables had, but what values they used to have (and how/when they
+changed).
+
+<p>
+As an aside, I'm one of those people who believes that an education should not
+be merely deep but also broad. I believe a good vocabulary, like a good
+education in general, enhances our experience of life. 
+
+<p>
+And as I thought about my old whiteboard shenanigans, the word that came to me
+was <i>palimpsest</i> -- a beautiful, useful, poetic word that we rarely see nowadays.
+It's sometimes used figuratively; but the literal definition is <i>(a</i> document on )
+<i>(which</i> the original writing has been erased and replaced with new writing).
+
+<p>
+I thought about the many older modes of writing, such as clay and wax tablets
+and papyrus. Some materials such as papyrus and parchment (vellum) were rather
+limited in availability or moderately labor-intensive to produce; people wanted 
+to re-use them. It was natural to wipe (or scrape or clean) such a material 
+once the writing on it was no longer relevant. The term "blank slate" <i>((tabula</i> rasa)) 
+was once very literal; the stuff we wrote on was the same as the building material.
+
+<p>
+By the way, what is deemed relevant may change over the course of 1,000 or 2,000 
+years. Many an archaeologist or linguist has spent countless frustrating hours
+trying to decipher the original writing under some later inscription. In a 
+similar way, art experts have gone to enormous lengths to uncover artworks
+which someone painted over rather than start a new canvas.
+
+<p>
+But what if writing materials were cheap? Today we are much more likely to
+have notepads on our desks than little erasable slates or wax tablets. 
+
+<p>
+Let's extend the analogy to computer memory. There was a time, perhaps four
+decades ago, when it was expensive and limited in availabilty. I recall seeing
+an information sheet about a mainframe ("What's a mainframe?" asks everyone
+under 40) that listed its specs, almost bragging about its memory, which was
+448K. Yes, that is less than half a meg. That computer ran a medium-sized 
+university. Within seven years, of course, people were carrying around floppy
+disks that held three times that much. ("What's a floppy disk?" asks everyone
+under 30.)
+
+<p>
+It was only ten years or so prior to that time that the world saw the creation
+of this curious thing called UNIX (a play on the name MULTICS). Some of you
+reading this may have wondered (or not) why UNIX and its offspring stored a
+conceptual newline as a single linefeed character (rather than the somewhat
+more sensible "carriage return + linefeed" combination. The answer is that
+the designers wanted to save RAM and disk space. For every line of text, they
+saved an entire byte in this way. When a linefeed was sent to a device such
+as a terminal or printer, the OS typically converted it to a "real" CRLF pair.
+This all happened because memory was scarce and expensive.
+
+<p>
+It isn't true anymore. In some cases, we may have learned bad habits and 
+forgotten how to conserve memory. But in general, we have more imortant things
+to worry about now.
+
+<p>
+But let's think a minute. If memory is cheap and available, why are we
+turning it into a palimpsest? Isn't there something to be said for the idea of
+leaving data alone, never overwriting information, always writing new data
+somewhere else?
+
+<p>
+If we do that, we have a "history" of what has happened in program execution,
+like a trail of breadcrumbs. More importantly, pieces of code that run
+concurrently need not worry about stepping on each other's data. One process
+(or thread or fiber) will never write over an item that another process is
+reading. If this doesn't eliminate synchronization issues, it at least
+mitigates them greatly.
+
+<p>
+So I'm starting to see where immutable data could be a good thing. And I'm 
+starting to see how it's good for concurrency. And concurrency really matters,
+because it is the limiting factor of this generation of computing just as
+memory scarcity was a limiting factor one or two generations ago.
+
+<p>
+In fact, I'll speculate a little about memory in general. Let's look 10, 20, 
+or even 50 years into the future. (My crystal ball, like everyone else's, is 
+very cloudy.) 
+
+<p>
+I can imagine a time when memory is simply never erased at all. We're seeing
+the crude beginnings of this already. Source control systems and databases
+preserve far more history than they used to. My laptop's OS encourages me to
+think of my backed-up data as a sort of limitless archive of past versions of
+files. It's mostly an illusion, but it needn't always be. Why should any
+document, any image, any video ever be erased? 
+
+<p>
+Food for thought. Chow down, friends.
+    </div>
+  </article>
+</body>
+</html>