All posts by april ellington

Devlog – SoundCloud upload is back!

Uncategorized

As some of you may have noticed, for awhile now, the MVGEN SoundCloud functionality wasn’t working. There were other things going on at the time that took up our time. One of our team has moved cross country. I recently got a new dayjob that’s been taken some time to straighten out schedule-wise. And also to get the day to day routine down. 

But suddenly one day in the last 4 or 5 months SoundCloud stopped working. There was much hand-wringing and gnashing of teeth at the prospect. It was mystifying, we didn’t know what might have changed and I at the time didn’t have the mental bandwidth to think about it, as I mentioned, other things were going on.

We did get some good error message feedback, which is always the starting point in an issue like this. At first blush, it appeared to be a upload tool version issue. But that wasn’t it. Then, I thought maybe the URLs we were using weren’t escaped or typed in correctly, that wasn’t the issue either. Finally, I capitulated and went with the prevailing wisdom (began to agree with John that the issue was with the version of Python running on the server). We went around the bush a couple times trying to get Python updated, installing mod_wsgi into Apache so that it would accept Python apps and serve them to the web.

This created a whole different suite of issues. Mainly, I inadvertently knocked out PHP when attempting to get mod_wsgi installed and configured. Then, we had more issues with a daemon that everyone forgot about until the last minute that was breaking the video creation step. Finally, we got that fixed – all of which took the better part of Sunday – and then I looked at the SoundCloud issue again with fresh eyes. I started to put the youtube-dl tool through the paces. Every time it errored it gave a recommendation: “see the youtube-dl –help for more details.”

I checked through this and found a way to enter username and password info, and some other interesting tidbits that allow you to ***. None of this really helped though. So I took to Stack Overflow. And yes, maybe I should have looked there first but when troubleshooting one must move systematically. I quickly found an article that explains how to use the SoundCloud API to download a song by the track ID. And there it was, the crack of sunlight shot through the end of the tunnel. I could taste the beginning of the fix coming, and it would be sooner not later.

So after some clicks and copy-pasting I got a API URL with the track ID in it. I plugged that into youtube-dl et voila! No more SSLv3 error message, in fact there was no error message at all, the mp3 downloaded and the verbosity of the output told me it was the song I wanted and the correct artist name and track name. Halleluyer! This was it, this was the workaround, and no Python upgrade necessary! And let me talk about that a bit too.

Updating Python outside of what comes with the OS is a HEAD ACHE. I don’t recommend it, in fact virtualenvs exist seemingly, solely for the purpose of being able to run another version of Python alongside the system version without clobbering installations. Even if you get a 2nd Python version running you have to reinstall ALL of your modules and dependencies. Along with this being a waste of space, it’s just bad because what if something gets crossed up in the process? Bad scene for business.

At any rate, since I got the API track ID working with youtube-dl it was only a matter of adjusting our backend code a bit to work. This is where John valiantly jumped in and saved the day. In a matter of a few hours he’d coded the workaround into our main branch and suddenly SoundCloud upload was working again!

It’s been a long time coming, and we learned a lot in this process. Much of it had to do with patience and tenacity and good old fashioned troubleshooting the latter of which seems to be a skill I’ve done well to master over the years. 

Enjoy SoundCloud upload everyone!

Happy Generating

Design Log – June 2017

Devops, MVGEN, News, Startup Life, Tech

“The extent to which you have a design style is the extent to which you have not solved the problem” — Charles Eames

Today I got an amazing amount of things done. I started early, so maybe I should rethink this “not being a morning person thing.” I got to this coworking space at almost 9 AM! I got some school “paperwork” stuff done immediately and then I started on the MVGEN end of things.

John and I discussed his desire to do more outreach starting this week and I suggested I could whip up some quick and friendly example/boilerplate emails for the verticals he’d like to reach out to. I offered to help with this because at the moment I’ve got time to help out where I can and I need to keep my writing muscles in shape because it’s a skill I don’t use enough these days. I got 3 of the 4 “press” templates cranked out faster than expected. These are: Soundcloud, Youtube Channel(indie) and Tumblr GIF creators. I haven’t started the 4th one, the generic “Press” template because I need to think more about it and maybe look at some good examples. Once I emailed and slacked those to him I pivoted and started on the MVGEN mobile redesign in Sketch. It’s weird because I’d been so intimidated by that software for as far back as I can remember. It’s amazing how much reading the instructions will point you in the correct direction :).

We’ve needed a mobile interface for aeons now, but I didn’t have the headspace for it. I realise that’s an excuse but at the time I’m being idle it feels reasonable not to even start without the appropriate motivation. At any rate, I’ve started (finally) on mobile (iOS) views for all the desktop pages on MVGEN.com.

I’m embarrassed to say this but the thing that really put the fire under my ass was finally looking at our Google Analytics (GA). Lo and behold, a cursory glance at a pie chart and some percentages and it became abundantly clear: the vast majority of our users create videos from their mobile devices. GA is granular enough that it shows which screen resolutions are most used. A quick search later and I learned a great many of our users are on the iPhone 6 plus.

I won’t be done quickly with this, but it does feel good to start the process finally. So now I know I need to make an iPhone 6 Plus friendly interface (phablet) and a smaller screen interface and larger format (tablet) interface. I sent John a quick screenshot of my progress so far and he seemed good with it.

Likewise, I finally get why designers extol Sketch’s praises from the mountaintops. The steep learning curve I’d convinced myself of is just not there. Especially if you’ve used Photoshop/Adobe apps to any depth. Everything is laid out cleanly and all the components you need to build a wireframe or mockup or prototype are laid bare, in easy reach. I got all the views for MVGEN mobile started in what seemed like minutes. So for anyone that’s been hesitant or unsure about trying Sketch or moving from Photoshop or something similar, I highly recommend it.

DevLog – June pt 1

Devops, MVGEN, News, Startup Life, Tech

I’ve been keeping the Buffer full of links and headlines for the last week or more. It’s been good for our engagement and adoption rates. Today I got us signed up for Mailgun which we’ve decided to use for “transactional email” (think confirmation messages and password reset emails). I also setup Mailchimp for newsletter purposes. For some reason I thought we’d already registered for Mailchimp but it looks like we hadn’t. As promised Mailchimp has lots of beautiful HTML email templates to choose from. I’d like to use Mailchimp for both but their API (Mandrill) is no longer a part of the Forever Free plan. Somewhat surprisingly, Mailgun also has email templates, so I’ll be sorting through and picking one or more of those as well. Mailgun also offers 10,000 outgoing emails a month for free, that should be more than enough to start. Once we grow past that point, it’ll be time to look at Amazon SES, another transactional email service, but as with all Amazon’s hosting and internet IaaS’s, the documentation can be a little byzantine.

I was somewhat frustrated by developer API access for Facebook today. They have so much available on their developers dashboard it’s almost daunting. I did not find the documentation overly transparent. It’s not dense like Amazon’s but kinda unclear and all over the place. Please, just tell me what each of your offerings does in the 1st 2 or 3 sentences. Is that so much to ask? This is somewhat a pet peeve, there are so many well documented services (free and otherwise) on the net that it’s always jarring when you stumble into a popular social media service that has opaque user guides and HOW-TOs. I’ll have to try it again another day, I quit after an hour or two because I’d end up going down a rabbit hole of frustration and teeth-gnashing which would leave the other tasks I had slated for completion/attack today unfinished. It’s been said before but there’s always something to do at a startup. So it’s best to maintain traction and momentum wherever possible.

Email the Gift that Keeps on Giving

Devops, Startup Life, Tech

The MVgen team has been working hard to roll out cool new features as quickly as we can. Everyday we’re one step closer to seeing our tool grow into the app everyone thinks of when they want to create a music video. This past week, we got even closer still to that goal as well as working toward positioning ourselves for outside help. You may have noticed that Ads came in as of a couple weeks back, and user accounts are live at LONG last. Director and Hacker extraordinaire, John set them live — perhaps a bit before I was comfortable with  — but that put a fire under me/us to make the user accounts piece as seamless and user friendly as possible.

We hit a major hurdle though as we decided to get more “professional” with things and a) get official @mvgen.com incoming mail to work, and b) have user account emails transmitted appropriately/securely.

Back on Nov 29th user accounts were sending properly, meaning they were TLS encrypted and not sent to everyone’s spam folder. This changed as soon as I began adjusting Postfix/Dovecot settings to get both incoming and outgoing mail working  — at the moment we’re using gmail for SMTP, which is fine as long as we don’t hit their limit for number of emails sent out daily for a specific email address (1000 i think?). IF we ever get more than 1000 emails sent in a day, we’ll have to shift to a different method for SMTP, but like always, we’ll cross that bridge when it comes into view.

Right around Dec 1, email started not delivering and then also getting dumped into everyone’s spam folders. There’s a laundry list of things you have to do in order for google to allow you to use them as a SMTP relay, 85% of which I took care of back in October when I first started working on the email bit of MVgen user account setup. Even though I used the ISPs official documentation for setting up Postfix and Dovecot shit wasn’t working anymore. Suddenly, we started to get IPV6 PTR record errors (reverse dns) and lack of encryption messages and also that there wasn’t a valid PTR record for the mail server’s hostname? Some of this I was able to resolve by adjusting what was in our MX, TXT, and SPF records but there were still configuration issues. 

I lost count of how many test emails I sent to myself and John and how many times I created new user accounts on mvgen.com to see if they would again be labeled as spam. I was led astray by sites like www.mxtoolbox.com, only to be saved by intoDNS.com. We signed up for things like dnswl.org and postmaster.google.com. 

John ended up encrypting the outgoing message for new user within the front-end code, probably a good idea in the long run, and we went a couple rounds about whether to make the sender address the a valid gmail address or not. At some point in our testing, both a valid gmail and a perhaps not so valid domain email seemed to work. We eventually went with the former.

Truly, the biggest hurdle was the fact that he’d already setup mail on his VPS and it had worked at some unknown point in the past but he never really needed to use it regularly. And when setting up Postfix/Dovecot/MYSQL to work together emails, passwords and everything goes through Mysql. This in itself isn’t a bad thing but I came *this close* to switching to to another db because I couldn’t get dovecot to authenticate to mysql. It was impossible to do anything with mail until that part was fixed. Time and again I saw the same standard mysql authentication error in the mail.log. After about half a week I took drastic measures. There was nothing on google that was helpful. I’d reset mysql passwords and backed up and recreated the mail database to no avail. Nothing worked. And since it was the standard password error, there wasn’t any real detailed help available on google. This sad reality is something you’ll see a lot if you’re ever troubleshooting an issue that seems unfixable yet common. Nobody will help you because it’s assumed you’ve fat-fingered the username or password. In this instance, that wasn’t the case. However, there were a couple things I would have done differently in retrospect. 1. I would have started all over again with the mail database and user. 2. I would have named the username and db name the same thing via the handy menu in phpmysql. 3. I would have flushed privileges EVERY TIME I made a change to the database. I found out rather late in the process this was a crucial misstep. 

After some final massaging of configuration files not only do mail messages get received by the MVgen staff successfully, the mail sent from the website isn’t sent to spam or un-encrypted. And it only took about a week of hand-wringing and hair-pulling. Jeezy petes. Now to move on to more interesting projects, there’s always something to do in a startup, right?