Monday, March 26, 2012

Not "What is Writing's Future", but "Does Writing Have A Future?"

Does Writing Have a Future Book Cover
Source:  Tower Books
Does it? What a provocative question. I often wonder what writing will look like in the future, but I never ask such a bold questions as whether or not it actually has a future. Of course it does, right? Or does it?

This question is the title of an extremely thought-provoking and “chewy” book by Vilem Flusser. I say “chewy” because it provides some really somewhat thick ideas that the reader is best served by moving through slowly and thoughtfully, ruminating on carefully. I’ve found doing so particularly rewarding.
This book strikes me as a must read because it addresses questions that are important for me as someone who defines herself as a compositionist most of the time, but a writing teacher at other moments. Being introduced to Flusser’s work is also important to me. According to the author of the forward, Mark Poster,
“Like both McLuhan and Baudrillard, Flusser theorized media culture well before many other cultural theorists thought seriously about it” (Kindle Location 45).

 Flusser’s ideas were well ahead of their time, but since he wrote in German, his ideas were not widely accessible to monolingual, English speaking scholars like myself.

The opening chapters of Does Writing Have a Future provide an introduction to the project of Flusser’s book and then begin to trace the history of writing. One thing that I really enjoyed from these opening chapters was the way in which Flusser was able to claim an already coined term for his own purpose. He takes the word superscript and opts to use it to describe the meta-writing he’s doing in his work. He says,
“Thinking and writing about writing should really be called superscript. Regrettably, that word is already in use and means something else. But it doesn't matter: with permission, the word superscript will be used with the new meaning suggested. Aren't there people who would call such violence against language ‘creative’?” (Kindle Location 245).
I love this notion of repurposing language, but I wonder why he wouldn’t have been comfortable with metascript.

Having established his task in the book as being superscript, that is the writing about writing. He begins to outline what he feels writing does for the world. Flusser argues that historical consciousness was not possible before writing. In fact, he argues there nothing happened before writing. Bold right? He says:
“It is therefore an error to suppose that there has always been history because things have always happened, to suppose that writing only recorded what had happened, to regard historical time as that period in history when people recorded events in writing. It is an error because before writing was invented, nothing happened; rather things merely occurred. For something to happen, it has to be noticed and conceived as an event (process) by some consciousness” (Kindle Location 270).
From statements like this one I began to really dig the writing of Flusser. I find his propensity for language really captivating. He achieves quite a bit through playing with the nuances of language. Nothing happened; things merely occurred. He argues that writing makes this happens. Part of the reason for this is because writing forces the spirit of an event into some form of permanency. To demonstrate this, Flusser traces the history of writing beginning with its roots in Greek and Latin. He shows how writing, entomologically speaking means to scratch or dig. Early writing was not a matter of writing on something, but rather in something.

This short video from PBS gives nice evidence of this fact. It traces the history of writing to its roots and provides examples of early writing. You notice from watching this video that writing was originally about digging into a tablet using a stylus, not writing on a surface.

Watch History of Writing on PBS. See more from History Detectives.

This observation about the history of writing is important for Flusser because he describes how writing as inscription is tied to stories about the forming of humanity itself.  First he reminds us that the term writing is linked to both the ideas of both scratching, as we think of when looking at the work a stylus does, but also tearing.  Then, he describes the narrative of the creation of human kind.  He says,
"God forms his likeness on clay to bury his breath in this likeness. God inscribed not amorphous clay but an image. He wrote not against the given (the datum "clay") but against something made (the image "God")-against a fact, that is [...]  According to the myth, God tore his likeness apart (no matter whether we take this likeness to be an anthropomorphic doll or a tablet) and, in so doing, wrote us" (Kindle Location 320 and 337).
With this narrative in mind,  he argues that what we lose by abandoning writing is the connection to narratives such as this one:
"What will we give up when we replace written codes with other, more efficient ones? Surely all those anthropologies rooted directly or indirectly in the myth under discussion here" (Kindle Location 337).
This evolution just makes me wonder if we will abandon such anthropologies or simply rewrite new ones.  I wonder if this metaphor of writing is really central to this creation story or whether we might write new ones that appropriate new media technologies.

Besides--as a believer in the Biblical creation story, I cannot say that understanding the metaphor of God writing us into existence was really necessary to my understanding of creation, since I never thought of it in that manner before reading Flusser's account.  This new understanding of the creation story does give me something to play with mentally, however, as someone of faith who specializes in writing.  I am personally very interested in looking at concepts of theology and their relationship to writing and words.  I get caught up in the meaning of John 1:1, for example, far too often.  However, that's a story for another day.  I'll blog about that later next month after I get my logos tattoo.  ;)  Stay tuned!


Flusser, Vilem. Does Writing Have a FutureMinneapolis: University of Minnesota Press, 2011. Kindle Edition.

Monday, March 19, 2012

Rails 1. Cheri 0...or maybe 0.5.

Continuing to Do Very Little with Ruby on Rails

After setting up the first application in Rubly on Rails (see my last post on my Ruby progress), the tutorial I was following walked me through the steps of signing up for GitHub and then Heroku and connecting the first application to these services.  

GitHub is a tool that serves as version control. What's cool about version control is that when you accidentally mess up your code, which for me isn't so much of an issue of "if" but rather "when," you have a safety net.  You can revert back to the last committed code on GitHub and pretend you didn't accidentally just mess up your application!  Nice!  It took me a long time to get my application synced up with GitHub.  Signing up for GitHub itself was easy enough, but then I had to connect my local files to the GitHub account.  To make this work, I had to learn about SSH key first, learn where to find mine and how to connect my GitHub account up with it.  Of course, really what I did was skip over the line in the tutorial book that said, after saying you should sign up for a GitHub account "You might have to read about SSH keys first" (Kindle Location 808).  Because I skipped over this, I spent about an hour banging my head on a wall when my application wouldn't connect up with my GitHub account.  Note to self:  pay attention to stuff in the parentheses!   

Nevertheless, I got to see my "first_app" files all safely hosted at GitHub, as this Screen cap shows:
GitHub Screen cap showing first_app files
GitHub Screen cap showing first_app files

Heroku gives your application a place on the web to live so that you can deploy it.  It's really a simple tool to use, once you know what you're doing with Terminal and GitBash.  You sign up for a Heroku account, then you gem install Heroku, tell Heroku your SSH keys and then use Git to push the application to the repository.  The image below show's the start of that--and how if you misspell things it will give you an error.  HA
Screen cap of Heroku install and SSH set up
Screen cap of Heroku install and SSH set up

Fair enough.  The push process was incredibly slow, especially on Panera's wifi ;).  Here's a Screen cap of the progress after about 10 minutes--that's right, 5% written.  
Screen cap of push to Heroku, 5% written
Screen cap of push to Heroku, 5% written

After I let the push run the first time, I got an error message that said:

error:  failed to push some refs to ''

Bummer.  So I did some research on this and found that some folks had success using some tricks with the git remote command to work around it.  No dice.  I end with this:

Screen cap showing failure to push to Heroku again.
Screen cap showing failure to push to Heroku again.

All this did is help me to create a new respository name (pure water rather than young mountain) to fail at syncing with my account.  I still have not been able to figure out what my hang up is here.  I've searched the forums, but haven't quite found a solution yet.  I'll have to keep digging.  The trouble with working with GitBash and Terminal in general is that there seem to be so many things that can go wrong.  My understanding of these processes is just enough to be dangerous, but not deep enough to know what I need to solve problems.  It's frustrating, but it gives me renewed appreciation to the depth of knowledge that developers have for this stuff.  I admit defeat.  For now.  

End of Tutorial Time Reflection:  So how far have I come?
Alas!  I have made it through Chapter 1 of Ruby on Rails 3 Tutorial: Learning Rails by Example, give or take the successful push to Heroku.  As the author, Michael Hartl, says in the conclusion of Chapter 1:  "We've come a long way in this chapter:  installation, development environment set up, version control and deployment" (Kindle Location 958).  It's true that I have come a long way and accomplished a number of things, but it really doesn't feel like progress because so much of the progress has been mental and in problem solving rather than visible.  

I have gained quite a bit in terms of understanding what goes on below the surface of development.  I have learned a wide variety of commands in terminal, I have learned to work in GitBash, and I've become familiar with tools for version control and hosting applications.  I learned about SSH keys, which previously I had no idea existed.  Now that I've worked through all of this, there's only one thing left to do.  As Hartl says at the end of Chapter one:   "All that's left is to,  you know, actually start learning Rails"  (Kindle Location 960).  

Yikes.  So I learned the foundation that I was missing, and not realizing I was missing, so that I can begin web development using Rails.  I learned how much there is to know and how much I really don't know.  What I would like to do now is slow down, back up and start moving through this again.  I need to spend some more time researching Git commands and getting to know not only what the commands are, but what those things actually do.  I need to learn more about Gems and how they really work within the greater framework of Ruby and Ruby on Rails.  What do they do?  Once I get some foundation under me, then I can start really playing in Rails.  But, alas, I really needed to learn to crawl before I started trying to jog.  Or Joggle, which might be a better description of what I was trying to accomplish.  

In the future, I still would like to develop a web application from the ground up, but I've got quite a bit of growing to do first.  That--and I need to find myself some Rails nerds to hang out with.  The forums are useful, but they only go so far.


Hartl, Michael Ruby on Rails 3 Tutorial: Learn Rails by Example. Pearson Education, 2010.  Kindle Edition.

Friday, March 16, 2012

Considering Examples of Ruby on Rails

As I’m beginning to play with Ruby on Rails, I’ve also begun to think about web tools that are currently running on Rails and what they are capable of. The Ruby on Rails website gives an extensive list of sites that use Rails:

First, I found it hard to determine which sites were using Ruby on Rails, because, since I’m not a developer, it wasn’t clear to me how to look for those signs! I’m used to viewing the source of a page to look for makers that it was built with CSS or to look at how it’s used HTML, but nothing that tells me what’s going on behind the scenes at a deeper level. I found this handy site, called Built With, however, which helped me mine quite a bit of information about any website I wanted to know about!

From Built With, I saw that use of Rails has been fairly consist over the last year, with not too much substantial growth.

Graph of Ruby on Rails usage of the last year, showing minimal growth
Source:  Built With
While I had heard that Twitter was built with Rails, Built With did not indicate that, so I looked into Twitter’s development further and found that they’ve been slowly moving away from rails over the years. However, other big name sites like Github and Groupon continue to use the resource. From Built With, I learned that the platform is largely used for shopping and business resources.

Graph of Ruby on Rails usage by industry; Shopping and Business have greatest precentages
Source:  Built With
One thing that I’ve found in examining these sites and researching their usage of Rails is rails is powerful, but also subject to certain vulnerabilities. Let’s start by thinking about their power. Rails sites are powerful. They are able to handle robust amounts of information and able to customize what information is delivered to a user based upon specific parameters they establish. For example, Groupon allows users to specify the geographical location and then the content is customized based upon deals available to that region and based upon the temporal availability of the individual deals. Rails helps facilitate this process of selecting data to display based upon parameters. Twitter is similar in that it selects tweets to display based upon what each user has specified in terms of whom (or what) they wish to follow.

Unfortunately, however, Github was recently the victim of a some pretty serious hacking that was the result of exploiting one of Ruby’s vulnerabilities: mass assignment vulnerability. Now, I don’t really know what that entails fully, but I know that it allowed the hacker quite a bit of access to files wherein he could have done some serious damage. Luckily for Github, the hacker seemed to be mostly trying to prove a point about the vulnerability, rather than do something malicious (More on that from Ars technica). However, it seems like to protect your site’s material best, you really need some intense understanding of Ruby programming in a way that I just don’t have yet.

As I think about what these sites are used for and what they accomplish, I cannot help but wonder whether Ruby on Rails is really a useful tool for me to explore for the purpose of making a personal portfolio site. It would be a powerful blogging platform, for sure, which would allow me all the customization I could possible imagine. But is the flexibility it affords really worth the trouble of learning the development process? Would I not be better off learning to customize a blog platform in a far deeper manner, including developing and modifying my own themes. I’m not sure, but I think I need to further explore whether I am learning this tool to be able to say I know it, or whether I’m doing so in a purposeful way. I am really one that is cautious of adopting technology for technology’s sake, so this is really food for thought indeed.

Rails on *shudders* Windows...

Okay—so after I nearly killed my computer, I decided to be safe and play with Ruby and Ruby on Rails by booting up the side of my harddrive I rarely use—the Windows side.  My initial plan was to clear out that side and install Linux to play with Ruby and Ruby on Rails, but I decided just for giggles to try out installing Ruby 1.9.3 with Windows.  It is with great pain that this Apple-lovin’ gal says:  it was so much easier. 

With Windows, you have the option of using Ruby Installer  This page makes the installation of Ruby almost dreamlike.  You simply click on the big “Download” button and it downloads an executable program.  You run it.  Magic happens.  Now—I’m not ready to give up on my Mac and go running as a proponent for Windows, but this is a nice solution to help me continue on my Ruby on Rails tutorials for my New Media Theory and Practice class.  I’ll figure out how to get this happening on Lion this summer.  I will not be defeated!

Once I got Ruby 1.9.3 up and running on my Windows side, the installation of Ruby on Rails was pretty smooth.  I just had to take one pit stop to install Ruby Gems, which is a project manager for Ruby.  Using Ruby Gems, I was able to install Ruby on Rails with a simple Ruby Gems command.  From there I was finally able to move along to my first Rails application!

The only real trip up I ran into through this process was having to remember to change drives with in the terminal to where I had things saved.  This screen cap (below--click to view a larger version) shows two places where I got an error because I needed to change the drive my computer was looking for files in—first where I had the installer saved and then where I had my first application saved.   

Screencap of Terminal wherein drive changes were needed twice.
Screencap of Terminal wherein drive changes were needed twice.

I should note that at this point I started moving through Ruby on Rails 3 Tutorial:  Learning Rails by Example once I moved to the Windows side.  Within no time working through the tutorial from that book, I finally had a product of sorts to show for it.  I was able to create my first Rails application and then visit it on my local host.  Below is a screenshot of what I was able to produce. 

Screencap of My First App with Ruby On Rails
Screencap of My First App with Ruby On Rails (Click to view larger)

[Sidenote:  Yes, that second tab in this picture is from my Google search for how to do a screen cap when running Windows on a Mac.  The normal Mac command didn’t work and there is no print screen button on the Mac keyboard!]

Now, technically I did very little, but I think the fact that I was able to produce this preformed site so quickly speaks to the power that Ruby on Rails has for web development.   I’m looking forward to playing with these further so I can see just how far I can get with building a page from fake-scratch with the help of the tools Ruby on Rails provides.