Posts tagged “web”
Update: WebFaction released today a one-click installed for node.js, obviating Step 2 below. Leaving it in here for posterity.
Shiny “makes it super simple for R users like you to turn analyses into interactive web applications that anyone can use.” It’s a powerful tool with a relatively simple syntax. It’s great for local apps — but I wanted to set up a web-based app that others could access and that wasn’t beholden to Shiny and RStudio’s excellent beta server platform.
I host this site and a few others at WebFaction — an awesome service with little to no downtime, fast servers, and relatively flexible restrictions. Getting Shiny up and running on WebFaction required a little work.
Step 1: SSH into WebFaction. Follow the instructions on their website for your specific server(s).
Step 2: Make a source directory. Download and install node.js.
mkdir src cd src wget 'http://nodejs.org/dist/v0.10.20/node-v0.10.20.tar.gz' tar -xzf node-v0.10.20.tar.gz cd node-v0.10.20 python2.7 configure --prefix=$HOME make PYTHON=python2.7 make PYTHON=python2.7 install export NODE_PATH="$HOME/lib/node_modules:$NODE_PATH" echo 'export NODE_PATH="$HOME/lib/node_modules:$NODE_PATH"' >> $HOME/.bashrc
Step 3: Download and install R.
#install R wget 'http://cran.us.r-project.org/src/base/R-3/R-3.0.2.tar.gz' tar -xzf R-3.0.2.tar.gz cd R-3.0.2 ./configure --prefix $HOME make make install
Step 4: Make a temp/tmp/temporary director.
cd $HOME mkdir tmp chmod 777 tmp TMPDIR=$HOME/tmp export TMPDIR
Step 5: Download Shiny from source and install using NPM.
git clone https://github.com/rstudio/shiny-server.git npm install -g shiny-server/
installing from NPM directly did not work — Shiny would not launch. I believe this is because you’re not allowed root access on WebFaction shared accounts.
Step 6: Launch R and install whatever packages you need.
install.packages('ggplot2') install.packages('data.table') devtools::install_github("ShinyDash", "trestletech") devtools::install_github("shiny-incubator", "rstudio")
Step 7: Want plots to work? In your Shiny app’s global.R file, set
options(bitmapType = 'cairo')
Next up: a cron job to keep a Shiny instance running or to restart it if it goes down… and putting Shiny behind some light authentication to prevent pre-release apps from general consumption.
Kevin Delaney, a high school teacher at Wayland High School, notices a briefcase in his department’s storage room. He’s seen it before, opened it before, but hasn’t really explored its contents — he doesn’t know the treasure within.
After a quick scan, we realized that we had in our hands the astonishing personal collection of Lt. Col. Martin W. Joyce (1899-1962), the 46 year old Army officer who was appointed commanding officer of Dachau Concentration Camp just days after its liberation in late April, 1945. Among the 250 original documents are personal letters, an 85 page scrapbook, his military files, Dachau documents, and a photo album presented to him by Yugoslavian survivors, who credit Joyce and the Americans with saving the lives of some 32,000 survivors. It’s clad in blue and gray striped fabric of prison clothing.
Boston Magazine elaborated a bit on the papers and on Joyce:
Inside were the assorted papers—letters, military records, photos—left behind by a man named Martin W. Joyce, a long-since deceased West Roxbury resident who began his military career as an infantryman in World War I and ended it as commanding officer of the liberated Dachau concentration camp. Delaney could have contacted a university or a librarian and handed the trove of primary sources over to a researcher skilled in sorting through this kind of thing. Instead, he applied for a grant, and asked an archivist to come teach his students how to handle fragile historical materials. Then, for the next two years, he and his 11th grade American history students read through the documents, organized and uploaded them to the web, and wrote the biography of a man whom history nearly forgot, but who nonetheless witnessed a great deal of it.
“Joyce became the thread that went through our general studies,” Delaney says. “When we were studying World War I, we did the traditional World War I lessons and readings. And then stopped the clocks and thought, ‘What’s going on with Joyce in this period?’”
As the class repeatedly asked and answered that question, they slowly uncovered the life of a man who not only oversaw the liberated Dachau but also found himself a participant in an uncommon number of consequential events throughout Massachusetts and U.S. history. In a way Delaney couldn’t have imagined when he first popped open the suitcase that day, Joyce would turn out to be something akin to Boston’s own Forrest Gump—a perfect set of eyes through which to visit America’s past.
So cool and such an impressive, thoughtful way to teach a history class. The icing? The students built a website and put much of the content on the web before turning the collection over to the Holocaust museum.
I recently revamped my photos page. I wanted an interactive, cross-device gallery to display the photos. In the past, I had been using jbgallery, a slick tool that used jQuery. I was having a bit of a hard time getting it to work the way I wanted and it was a little laggy on iOS and Android devices, so I decided to part ways with it. I don't want to speak poorly of it -- it works very well and the developer is friendly, happy to chat, and works to improve his library constantly. It's a nice tool, but wasn't what I was looking for in the end.
Photoswipe looked rad and performed pretty well on my iOS devices (an iPhone 4 and a 2012 iPad with Retina Display). I decided to give it a whirl.
This is my first tutorial related to this kind of stuff - take it with a grain of salt. And let me know if there are blatant errors or better ways to do things.
Into the body of your webpage, you'll need to put the code pointing to the flickr call. Place this wisely -- it'll play an important role in making all of your photos appear in the proper place. As placement is a bit context specific, we won't go into details here. Play around with it or view the source on photographs if you have initial questions.
Open your favorite text editor and create a new file. Paste the following into it. Create a reference to it in your photo gallery page. We'll go through it in more detail below.
Our first line defines our function. Ce n'est rien.
Our next couple of lines set a newly defined variable -- retina -- to see if the Pixel Ratio > 1.
Our next four lines check that we're getting an okay JSON response from flickr. If it's not okay, things are going to halt. This could be due to a poorly formed request, a lack of API key, etc.
Next, we're going to get the number of responses (photos) pulled from our response. This will be important later. We're also going to define a couple of empty variables that we'll use later.
Now comes a bit of a headache. The comment explains how we're choosing a number of different photo sizes and building URLs to access them. Flickr recently revised its API, so for more information / to keep this thing up to date check out the official documentation.
We basically choose a large square image for the thumbnail for retina displays and a smaller one for non-retina displays; similarly, we choose a large image for retina displays and a smaller one for non-retina displays. This introduces a bit of an issue -- if a user is on Edge with a retina display, the image will load slooooowly. There are ways around this, but its a bit too much for me to deal with.
The next bits -- r+= and s+= -- build list items for each image. This chunk should be filled with code relevant to the layout of your page. If you're not using PhotoSwipe, you can adapt this to whatever you need it to be. Just be sure to keep track of the quotation marks.
If we have a retina display, we embed the retina images; otherwise, we embed the standard images.
And we're off! I made a number of other small tweaks to the PhotoSwipe JS to make it work the way I wanted. But, overall, this covers the gist of it. Download a copy of the script here.
Seems many people are on a redesign tear. All focused on readability and putting content front and center, and abstracting other elements to the background — navigation elements, ads, etc. Zeldman’s the latest — and most extreme — case. His site looks pretty amazing (and striking) and probably looks outstanding on retina-calibre displays (to be confirmed in a few minutes). If we believe the following, we’re blessed:
This redesign is deliberately over the top, but new ideas often exaggerate to make a point. It’s over the top but not unusable nor, in my opinion, unbeautiful. How can passages set in Georgia and headlines in Franklin be anything but beautiful? I love seeing my words this big. It encourages me to write better and more often.
But this is my personal site. There are many like it, but this one is mine. And on this one, I get to try designs that are idea-driven and make statements. On this one, I get to flounder and occasionally flop. If this design turns out to be a hideous mistake, I’ll probably eventually realize that and change it. (It’s going to change eventually, anyway. This is the web. No design is for the ages, not even Douglas Bowman’s great Minima.)
I don’t think you will see much type quite this big but I do think you will see more single-column sites with bigger type coming soon to a desktop and device near you. For a certain kind of content, bigger type and a simpler layout just make sense, regardless of screen size. You don’t even have to use Typekit or its brothers to experiment with big type (awesome as those services are). In today’s monitors and operating systems, yesterday’s classic web fonts—the ones that come with most everyone’s computer—can look pretty danged gorgeous at large sizes. Try tired old Times New Roman. You might be surprised.
The present day designer refuses to die.