{"id":21526,"date":"2017-05-17T16:22:41","date_gmt":"2017-05-17T16:22:41","guid":{"rendered":"http:\/\/bounce_hacking_jazzfest_with_social_videos"},"modified":"2024-08-15T14:06:17","modified_gmt":"2024-08-15T21:06:17","slug":"bounce_hacking_jazzfest_with_social_videos","status":"publish","type":"post","link":"https:\/\/cloudinary.com\/blog\/bounce_hacking_jazzfest_with_social_videos","title":{"rendered":"Bounce! Hacking Jazzfest With Social Videos"},"content":{"rendered":"

Last week, I was invited to an exclusive hackathon to build apps for musicians. The app team I was assigned to was tasked with building a video upload site for Bounce videos. Bounce is a style of music that originated in New Orleans. The app would be called BounceDotCom.com and there were plans to have Big Freedia<\/a>, the Queen of Bounce, promote it. I knew the organizer could make things happen, so I jumped at the chance.<\/p>\n

A Video Sharing App in 48 Hours<\/h2>\n

On the team was me, Brad Huber, and Doron Sherman, from Cloudinary. We had about 48 hours to make something happen. I showed up Monday evening, after the team had begun work, to figure out the plan and how I could help. There was a basic backend in Rails. I was going to come in early the next day and get to work on the frontend in JavaScript and React.<\/p>\n

Now, people may know that I prefer ClojureScript myself over JavaScript. But I\u2019m also a pragmatist. Although I think I could have done the job in ClojureScript in probably less time and code, I know that finding another ClojureScripter would be a difficult. It would tie the app to me. Any updates would depend on my schedule. Doing it in pure JavaScript would give much more flexibility, particularly for something where resources are tight and the future is unknown.<\/p>\n

The next morning, I got to work setting up the React frontend so I could test it. I used create-react-app<\/a> to get started. It comes with a dev setup so you can automatically reload your code as you save it. I\u2019m a big fan of fast feedback. The save-and-reload workflow is not as good as you get in ClojureScript, but good enough for a small project like this. In ClojureScript, you don\u2019t lose your current state when new code is reloaded, so there\u2019s much less clicking.<\/p>\n

The Challenge<\/h2>\n

My main focus at first was to get video uploads to work. I knew this would be the biggest challenge. Uploading files from multiple devices and posting to an API I was not familiar with was not something I wanted to mess around with on a short timeline. Plus, the app would be worthless without it. If people couldn\u2019t upload a video, the main concept of the site would not exist. Doron was a big help, providing the documentation when I needed it. Cloudinary offers many different solutions, including posting the video yourself or going through one of their widgets. For a 48-hour project, I chose a widget. There was no way I was going to trust that I could do it better in 48 hours.<\/p>\n

When you\u2019re working under sane conditions, spending a day to research your best option is well worth the investment. However, hackathon\u2019s are not sane. You want to quickly find something acceptable and move on. I found three different widgets that looked like they might work for our use case and our stack. In the end, the one that worked first was super easy. Just include this in the HTML:<\/p>\n

<script src="\/\/widget.cloudinary.com\/global\/all.js" type="text\/javascript">\n<\/code><\/pre>\n
Here\u2019s what it looks like:\n\"Upload\"<\/p>\n
And on mobile:\n\"Mobile<\/p>\n
That will fetch a script with everything you need. Here is how I show the widget.<\/p>\n
window.cloudinary.openUploadWidget({\n\tcloud_name: CLOUD_NAME,\n\tupload_preset: 'default',\n}, (err, result) => {\n\n});\n<\/code><\/pre>\n
You get the Cloud Name from your Cloudinary account. I had to create a preset in the dashboard that allowed for unsigned uploads so anyone could upload a video from their phone using only the frontend.<\/p>\n
\"Dashboard\"<\/p>\n
To display the videos, I tried cloudinary-react and it worked very easily.<\/p>\n
import {Image, Video, Transformation, CloudinaryContext} from 'cloudinary-react';\n\n<Video\n\tcloudName={CLOUD_NAME}\n\tpublicId={VIDEO_ID}\n\tposter={`https:\/\/res.cloudinary.com\/${CLOUD_NAME}\/video\/upload\/${VIDEO_ID}.jpg`}\n\tref={(v)=>this.video = ReactDOM.findDOMNode(v)}\n\tonPlay={()=>this.setState({playing:true})}\n\tonEnded={()=>this.setState({playing:false})}\n\tonPause={()=>this.setState({playing:false})}\n\/>\n<\/code><\/pre>\n
The component worked right out of the box, but we did have to fix some issues. It worked fine on desktop, but on my iPhone, the poster wasn\u2019t showing up. That\u2019s why I added the poster attribute manually in that code snippet. Problem solved. Luckily, Cloudinary is smart. If you ask for the .jpg file, it will give it to you and generate it if it needs to. If you ask for the .png, it does the same. It works better than you expect, because most services don\u2019t do this kind of transformation on the fly. But Cloudinary does, and it works the way you want it to work.<\/p>\n
Notice that I set up a React ref for the video. I wanted to be able to stop and start the video in my scripts, so I needed a direct reference to the video element. The react-cloudinary components render out to regular HTML video elements.<\/p>\n
How Do I Know?<\/h2>\n
I read the code. Yep, it\u2019s readable code. And when you\u2019re on the super tight deadline of a hackathon, you don\u2019t have time to read inefficient English text documentation. You go straight to the render() method. Code doesn\u2019t lie.<\/p>\n
Another thing I learned from the code was that if the react-cloudinary components don\u2019t understand a prop, they just pass them right down into the video element. So I could put onPlay, onEnded, and onPause callbacks right in there. A really nice touch.<\/p>\n
Then I Hit a Snag<\/h2>\n
The Cloudinary upload widget lets you upload videos and images. But there\u2019s no way to limit it to only videos. Well, not that I could find. If you said \u201conly .mp4 files\u201d, it still lets you take a picture and try to upload it. Then it fails and you lose your picture. For our use case, that is a terrible user experience. People are having fun at a party, they take a really awesome picture they want to share with their friends, but instead the app drops the photo on the floor. The uploader works fine, but our app was never meant to host images. I could write a custom uploader, but I didn\u2019t want to spend the time.<\/p>\n
\"Upload\"<\/p>\n
So what did I do?<\/p>\n
I made an executive decision: We would support photos. This required a small backend change that I could not make, since I am clueless when it comes to Rails and Ruby. We needed to record whether it was an image or a video along with the media id. I made the changes to the frontend that I could, and allowed images to be displayed, and recorded an issue for the necessary backend changes in the backlog.<\/p>\n
Here\u2019s how you display an image from Cloudinary:<\/p>\n
<Image\n\t\tcloudName={CLOUD_NAME}\n\t\tpublicId={IMAGE_ID}\n\t\/>\n<\/code><\/pre>\n
Super easy. The only thing I wish for here is that you could tell whether it was an image or a video from the id. I could query the API, but we wanted to minimize the number of requests to keep latency low. Plus, on mobile, each HTTP request is just another chance to fail.<\/p>\n
By Lunchtime, What Did We Have?<\/h2>\n
\"Video\"<\/p>\n
We could list videos (with inline playing and nice thumbnails) and upload new videos. We had a login system so we could identify users. Was it a nice app yet? No. Was it completely easy and straightforward? No, I can\u2019t say it was. But it was mostly forward progress. I mean, that was basically four hours of work to get video uploading with transcoding to multiple formats. Oh, and remember, it worked on desktop, iPhone, and Android with the same code. Not bad. And by \u201cnot bad\u201d, I mean wow! A video app in a morning! I did not imagine this was possible before I met Cloudinary.<\/p>\n
After lunch we started to put it on the open internet so we could have some kind of deployment pipeline. Until then, it was just me serving it from my laptop. We had some snags with that, too. For example, Heroku decided to upgrade its DNS to support SSL which did not allow us to add custom domains for a few hours. But in the end, we had everything hosted on Heroku.<\/p>\n
At this point, it was 6 p.m. I had been adding a bunch of stuff to the backend backlog, since as I said, I don\u2019t know Rails. Lucky for us, Brad Huber, my teammate, knew plenty. I had to run but I would be back. I was hopeful to have all of my backend requests finished when I returned.<\/p>\n
When I came back, it was on again. It was after 10 p.m. Some of my changes had been implemented, but not all. One of the things I requested was to be able to store arbitrary JSON data with users and with videos. In a hackathon, you just don\u2019t have time to mess around with designing a data model, and you certainly want to remove any reason to coordinate with the backend team. They have better things to do than add this field and that field to the model. It\u2019s much better to just let the frontend store whatever they want.<\/p>\n
The break from coding had given me a new perspective on the app. I had been thinking about it mostly as a desktop web app. And our backend reflected that. It required users to register and  login to upload a video. But after taking a break and seeing some issues logging in on some phones, I decided we needed to focus 100 percent on the main use case: the app would be demoed at a party the next night. People would want to pull out their phones, film some badass dancing, and upload it to share. They don\u2019t care about logging in. If they had to do that, they wouldn\u2019t have as much fun.<\/p>\n
How Did We Solve It?<\/h2>\n
We got rid of the login. You go to BounceDotCom.com, you click a button, record some video, and upload it. It shows up. You rock. That night, we recruited a couple of designers to draw some designs and implement it.<\/p>\n
And then we passed the point of no return.<\/p>\n
I hadn\u2019t eaten dinner. There was some food left I could scavenge from. And then Doron offered me a bubble tea. Great, I thought. It looked milky and those tapioca balls could sustain me. I started drinking it. And then I realized, too late, that it was coffee. I\u2019m super sensitive to caffeine, especially that late at night. I doubted I would sleep that night.<\/p>\n
And I didn\u2019t.<\/p>\n
I stayed up all night coding on this app. There were several things I needed to do. We wanted a strong viral component, so I added Facebook sharing. To do that you need some Open Graph metadata in your HTML and some JavaScript for Like buttons. I hacked on that through the night. But Cloudinary made this really easy. Here\u2019s a snippet from the HTML template:<\/p>\n
<meta property="og:image" content="{{&image}}" \/>\n{{#video}}\n<meta property="og:video" content="{{&video}}" \/>\n{{\/video}}\n\n\nThat {{&image}} and {{&video}} get replaced on the backend by this:\n\nif(pid && type === 'image') {\n\timage = `https:\/\/res.cloudinary.com\/${CLOUD_NAME}\/image\/upload\/${pid}.jpg`;\n}\nif(pid && type === 'video') {\n\timage = `https:\/\/res.cloudinary.com\/${CLOUD_NAME}\/video\/upload\/${pid}.jpg`;\n\tvideo = `https:\/\/res.cloudinary.com\/${CLOUD_NAME}\/video\/upload\/${pid}.mp4`;\n}\n<\/code><\/pre>\n
That is, we can generate image URLs and video URLs pretty easily for Facebook to use. Liking and sharing work pretty well. And it was thanks to Cloudinary\u2019s ease of use.<\/p>\n
\"Social<\/p>\n
Then, a Surprise<\/h2>\n
Travis Laurendine, the organizer, showed me that if you send a link over iMessage, it embedded the video right in there. Hello!! That was totally unexpected.<\/p>\n
I crashed pretty hard around 10 a.m. I took a four-hour nap. When I woke up, I loaded the app to find it purple and beautiful, thanks to those designers. I fixed some CSS and added a play button. Everything was coming together. I worked on it a little that afternoon, but nothing so intense as before.<\/p>\n
\"Demo<\/p>\n