Auth with Rails, Angular, and UI-router across domains

     So let me be the first to say that although I normally hate mixing front end with back end systems, especially opinionated MVCs like angular. Its really not as bad once you get used to it. But its not simple or easy most of the time, mainly because you need to understand the backend and front end systems like the back of your hand to fully appreciate how they work together. And I am no expert in rails or angular, but like many developers, my job expects me to get my shit together and make it work.

   Our first problem was that we could not use Devise, because we are sharing across domains, and we cant use CORS because some of our users still use vista. So we are instead sharing tokens and data using JSONP, and encrypting and decrypting with a custom build. Not really perfect, and I would have loved to use CORS instead, but sometimes you need to get creative.


    So I am starting this tutorial assuming you already have a rails/angular app created and integrated. If not i would suggest this tutorial to start you off. And I am also assuming you need to build your own auth that does not use devise. So first some stuff you will need to use and might want to read up on in case you have not yet. First thing, services, they are great, and if your new to angular you might not have used them yet, especially if your project is still young and mostly in controllers. Two, localstorage, this will keep our important variables saved even after page refreshes. Which by the way services will also help prevent as you will see soon.

  So well start with the routes first, I am assuming you are using ui-router, and if not, I would HIGHLY suggest you try it out. Its much better at routing then the standby angular comes with, at least for large projects, and especially projects living inside backend systems.

 Just to make sure we are all on the same page. Your rails routes should look something like this, and your controller should look like this.

While your angular routes should be way more robust.

    As im sure you can guess you'll need to add authenticate to your routes, put true if you want them lock them up from non-logged in users, and false otherwise. Also just in case you dont know this yet, please keep in mind that the home route is the route that will feed in from your application.html.erb file.

   As you can see i have a few more routes, including login and all have authenticate on them. Make sure you add the otherwise to the bottom of your routes, and set it to your login page(if thats what you desire).

    So then make sure you have ngstorage installed, i link to it earlier in the tutorial. Make sure its in the app and in the require slot, all that good stuff. Then we can start to get into the fun stuff. Lets put all of this into a file called auth.js, or if you want, authService.js/authCtrl.js, does not really matter.

 So what this does is every time your application starts running and you are changing your routes, like clicking to new pages. It checks to see if you need to be authenticated, which we specified on the routes earlier, and then what your AuthService says, either true or false. If you are not authenticated then it takes you to the login page. Thats what state.transitionTo is for.

So your service will look something like this, you at least probably need a few of these, but you can omit filter.  And inside your service we will have three functions, log in, log out, and isAuthenticated. We will call these functions in the app.run and in our controller. Well start with isAuthenticated.

So this is pretty damn simple, we saved a boolean value in a local storage variable called AuthAccept, and when we call that variable we are looking to see if its still true or false. So now we can go check out our log in function which has all the magic.

 Okay so when we call this in our controller we are going to pass it two variables, the email and password. As you can see we send these values in a JSONP object that returns a failure or success message. If it fails we pop up error messages, and if they are a real user we save a few things to local storage. Now if your using CORS you will do this with a post request, and will have way less code, and all the power to you. But if your unlucky and have to use JSONP your code will look closer to this. Once you confirm that the user is a real one, then you need to set AuthAccept = true, and put it in local storage, this saves that our user is logged in. And you can set the state.go to home, or wherever you want your users to be directed.

 This is the logout function, basically you just need to clear out all your local storage variables, especially AuthAccept, and send them back to the login page.

So now we can look at our controller, its pretty simple, just calling the functions in AuthService from a click event. But what you might take not of, is if you need your local storage variables in the scope you will need to set them equal to a scope variable, as im doing here. I use this to hide my footer and nav bar among other things.

And thats basically the gist of this tutorial, if anyone has questions or concerns feel free to comment.

Practice makes Perfect

      So now that I have finally settled down into my job, which has taken longer then I expected. I plan to start writing for the blog again once a week, with a combination of technical advice too actual blogs about my technical feats. Though i must admit that I dont find it to be a good idea to post what I am accomplishing at work, which is a shame, because im doing all kinds of cool stuff, but i digress.

    This post is mostly for us newbie programers, and maybe some of our older more experienced developers as well. But I have realized that it is important to continuously practice interview problems. Now I know what your thinking, they suck, you dont need them because you have a good job/loads of experience. But I think its important for us to do these problems when we are NOT trying to find a job, even once a week would be enough. You know why? Because they suck horribly when your looking for a job, they are stressful and you are constantly questioning yourself while doing them. They dont even really help you with becoming a better programmer, they just make you dread the interview experience. No matter how great of a developer you are, these problems probably stress you out, especially since they can range anywhere from normal 15 minute questions to 3 hour long I need a degree in math to solve this crap hard. And if your interviewer is worth his salt he will make sure to give you one to match your skill level, which means even our most experienced developers should be ready to have these hard problems thrown at them.

     We all need to know right now that the way these problems are used in an interview setting and non interview setting are totally different. I would wager most of them are not actually meant to be interview questions, its just easier for everyone if we use these instead of creating our own, which honestly gives us developers a leg up. In an interview settings its all about solve this problem with none of the normal tools you would have at your disposal and in an uncomfortable setting on this whiteboard with an eraser that hardly works, have fun. You could say not all interviews are like this, some people let you use the internet, and allow you to use your computer, even run the code a few times, but a good chunk of interviews will be like i described. It was this kind of interviewing that made me HATE these problems with a burning passion hotter then the sun, I hated every second of doing them. But once i got a job i decided to go back to them and give them a second chance but this time without me being stressed to do them perfectly, or fast, or without the help of stack overflow and docs.

     I realized how great these problems were, and honestly how much fun they can be. They gave me a chance to solve problems that i would never get at my job, they reintroduced me to math terms and equations i hadn't heard for years. Once i had solved problems in my most capable way I also normally went to stack-overflow to see how the professionals solve the problem, and I always learn something new from them. They can take ten lines of code and turn it into one, they can show you a new way to solve problems that takes up less space and has a better run time. These problems are a great way to get you to think outside the box, read the docs, and find great tricks and tips. The best part is its okay if you cant solve the problem in less then 5 minutes, its okay if its been 5 months since you needed to convert a dictionary into a list and you need to review the docs. Because the point is to learn and get better, thats the ultimate goal of most developers. We want to solve problems better, faster, and smarter. But to do that takes time and practice, so im linking the sites I use as practice.


https://www.interviewcake.com/ - Subscribe to their weekly interview email, its great practice, and the problems are always original, out of the box, and never easy. Although they are more geared towards interviewing questions, the problems are great even if you aren't interviewing. Be ready to spend about 30 minutes to an hour on their problems.


https://projecteuler.net/archives  - Project Euler problems are pretty popular, they are a lot of peoples go to when interviewing, but they are way better when your not. You can go through their archives, it will probably take you at least a year to finish them all, and then you can move to the most recent.

http://coderbyte.com/CodingArea/ - Coderbyte is really great if you need to practice problems in more then one language, which is why I love them. Their interface and problems are easy and fun, and are organized from easy to hard.


I would start with these sources before going to crazy on anything else, and remember, practice makes perfect, but fun turns into passion and talent.

The Hackathon

Song of the Day: https://www.youtube.com/watch?v=MBHP8XmNMds

One of the one things I could not wait to do when I got out of my bootcamp was go to hackathons. For those of you not familiar with hackathons they are awesome, they are normally mulit-day events where a bunch of "Nerds" churn out projects for the chance to win money and prizes, and of course recognition and status. In the software and coding sphere hackathons are normally for the people who love a good amount of competition and quite frankly, love to code. You dont waste two-three days of your life coding away basically unpaid and stressed if you dont love to code. Which is also why people looking to hire programmers sometimes hang out at hackathons, because hackathoners might not be senior devs with years of experience, but they are serious coders with serious skills. So its time to break down hackathons into three categories, what and where, who and why, and how you win.

The Where. So basically a hackathon can be anywhere from one-three days, and it is normally hosted inside a hotel, conference hall, or software company. Some of these are what we call 24 hour hackathons, were basically its all you can drink red bull, basically you show up at 9am to start, and then present your project at 9am the next morning, and then go home and crash. Others are overnighters where you come in the morning, but you have the opportunity to stay the night at the hosting place and then normally you present your project the next day right before dinner time, so you might get like 4 hours of sleep at these ones. But many of the smaller and run of the mill hackathons are ones where you come during the first day, leave around 10pm and then go home and finish the next day. And for the most part hackathons have all you can drink redbull and do actually feed you, so you really dont leave the event space for any reason. Obviously the kind of event you have is mainly based on the organizers and how much money and time people have to dedicate to this.

The What. Hackathons first of all have themes, anything from cars, healthcare, space travel,google cardboard, to brain science. In order to win the big prizes you normally have to have the best idea that solves a problem related to the theme. So who pays for all the fun times? Sometimes its a company, especially if its a big one, looking at you google. But normally its a number of smaller companies and sponsors, who contribute money,food, staff, time, or prizes to the hackathon. The sponsers are normally then broken into two groups, those who actually participate, and those who just want their names on the hackathon website. The ones who just want their names out there, normally contribute food and prize money, and even sometimes contribute the actual event space. But many sponsors contribute, hardware, data, APIs, SDKs, and software that you use to actually win the main prizes and normally smaller prizes. Did I mention there is multiple prizes? The companies normally get to pitch to you in the morning about how you use (insert some kind of software related device) to win their prizes and then they normally have a small staff stay at the hackathon to help you if needed.

The Who. Now it might seem like hackathons are only for the coders and mega nerds, but thats not entirely accurate. If you are related software engineering in any way normally hackathons are for you, and now a days there are even no-code hackathons. And if you are related to the theme then the hackathon is also normally for you, for example I went to a neurogaming hackathon, and there were physicians and neural scientist there to help design brain specific health solutions. Some people go to hackathons just to get their great ideas and solutions built and then when the hackathon is over sometimes go on to create business our of the projects. But the majority of hackathon attendants are programmers all of different skill levels and languages, the only thing they all have in common is that they love to code and normally love to win.

The Why. So why go to a hackathon? Well normally people go to hackathons for three major reasons, they want to solve problems and have great ideas on how to do this, they want an excuse to learn a new technology and want to hang out with cool people while doing it, and of course because they want to win. All of these reasons are perfectly valid and the main reason that hackathons are so fun is because they attract all different kinds of people.

How to Win. Now this might seem pretty self explanatory for a lot of people, go in with a great idea and code it out and your good to go. But normally the people who win hackathons either have real strategies or are really lucky. The best strategies is to have already built a full team and have an idea ready to go, assuming the idea is good and the team works well together you have a pretty good chance of winning something. This is my main strategy is to go in with friends who I know will work hard and then go from there, were horrible with ideas but we will get better eventually. But for now we have won first place at the wavemaker apps world hackathon, and second place for the nsquare hackathon. For some people thought the best strategy they can come up with is to cheat by bringing pre-made code, its not cool and we hate you assholes who do this, you are not smart and awesome when you win, you suck and ruin it for everyone else. Nowadays judges have started to do code reviews to keep this from happening, especially at the larger hackathons with bigger prizes.


So remember go to hackathons if you want to and have fun with it!

AI, the computer that learns

Song of the day: https://www.youtube.com/watch?v=RKlJXpjeYC8


I am currently in the process of playing with an extremely interesting AI system called Josh, and it got me thinking about machine learning and what its really about. Right now Josh is just a version of Siri from what I understand. When I ask Josh from the weather he responds like Siri, they both go to an internet source for Josh its Wunderground and they determine my current location and give the weather for San Francisco. Its a simple request, but it also feels mechanic, theres no way of hiding that Siri and Josh are unintelligent, but behind them is a group of highly intelligent humans who have written hundreds of lines of code to make these machines respond to human request. Right now I am giving Josh a rule that if I request a song lyric he will get it for me from a website, and soon I will make it so he could return me a place from Foursquare. So maybe if I ask for Chinese food he can find some for me.

But yet to the average users these AI systems seem strange and cold, they are still not quite human enough for our taste. They are not quite smart enough. Our current AI systems can only take requests, and return to us data from a database or the internet. If you ask an AI system like Siri "what is love?", she would probably return a definition that she has in her database or one that she finds online. If you ask her "why does Fred not like me? I have called him eight times today", she might come up blank or just search that sentences in google and bring up a yahoo answers about clinginess. Siri lacks the ability to have an emotional response or even a critical thinking response, and to program her ability to be able to talk to you about why Fred does not love you because your clingy would take years, and thats just one question.


I think right now we are doing brute force AI's, we are hard coding everything they do. But the real question is it possible to hard code feelings and emotional responses? Maybe. Maybe Siri could start to recognize voice patterns and see when you are sad, and know how to mimic those patterns so she can seem sad as well. Can we trick ourselves is the real question. As we begin to understand the brain we have in our skulls, that sends signals to process data, very similar to our machine counterparts, I believe we will eventually be able to create a true machine that can learn and adapt.

But what is our end game for Josh and Siri? Do we want mechanical slaves or do we want something we can be friends with? Can Siri ever be my friend in the way a human being can be my friend. In theory I could have a Siri that has all my data, all my online profiles, my physical health, she could recognize my voice and speech patterns, and with all this data could she be able to "understand me" and be my "friend". She could probably give me advice, console me, fake love, but is this what we want? Are humans only a series of predictable algorithms made complicated by a brain? Creating machine slaves is easy, thats only the first step. But creating machines that can react to our feelings, feelings they will never have, thats the next step into dangerous territory. Will we have AI systems like in the movie "Her" that are able to "love" us and only want to learn from us, or will we have the terminator, or are the movies all wrong and we will go down a completely different path.

My favorite Bugs

Every Software Developer comes across bugs, its just a fact of life. Sometimes they are in the code, sometimes they are actual live bugs inside your computer. Im looking at you, people who eat on top of their computers, especially the ones who eat chips. But right now were going to talk about our favorite bugs, more specifically my favorite bug. Every programmer has a favorite bug, its the one that you do not understand no matter how much you investigate, and theres no answers on stackoverflow. Over the course of the past month I have dealt with many mundane bugs, that are easy enough to solve and fix. Normally they are problems I have created myself due to typos and normal beginner programmer mistakes, but my all time favorite is my wonderful called "Magical Delete Bug", and the best part is he's still on the lose. Although I dont actually believe in this meme, I still find it hilarious because thats basically how I described the bug to my teammate, a "special feature".

So the original problem for me to solve was our web-socket needed to delete the users location when they logged out. A relatively simple JQuery click-event that is attached to our log out button, so I had the logout button assigned an id of logout, and called the click event in my swampdragon code.

The funny thing is this code likes to work randomly, for the first week it would work on my teammates computer but would not work on mine. Eventually I had other work to do and this problem was not pressing, annoying, but not my biggest problem. But eventually I pulled from my partners code and the delete button started working, the funny thing? The code on the appropriate pages never changed, they were identical, I went through their history with my pycharm. It was all very suspicious, I assumed it was something to with the way the pages were being loaded. 

But then it got interesting, really interesting. For the sake of our presentation I needed us to stop deleting the users locations, so I commented out my code in the swampdragon ready function. And the code continued to function, as if it was never commented out. Now this was really annoying and for the sake of the presentation I just worked around it. But I already know that in coding things might not make sense as to why they are working/happening, but there is no magic. I already know that the reason the function was still working is because I did not restart the code, or at least its a good guess, and probably the closest I will get to the truth. Because now that I have returned to the code a few days later it has decided to stop working again. 

A lot of developers would probably think its silly to find a bug amusing, but theres something special about knowing a problem exist and getting to enjoy the cat and mouse chase of solving it without any real path to the solution. Theres no Django yellow error page, or the cryptic angular errors, its just me and my broken bipolar code. 

Id like to leave this post with an appropriate ending that I think currently describes how I feel about testing code.

 This is basically our entire projects testing in a nut shell. I am actually looking forward to writing some good old test cases for our project, making my life easier. I might not be completely sold on TDD, but I can agree that tests do make my life easier, even if currently write them after I write the code. But I will eventually flip the tables. 

Testing in Coding

     So I would like to say that I am so happy the classroom phase of RocketU is finally ending. It has been a long and exciting path, but I am ready to jump into projects at this point. We will be ending the classroom phase with a sprint on deployment, and I am so excited. I can finally get my horribly built with angular.js burrito shop online. Because everyone needs more burritos, and I spent way too much time building and debugging that shop just to let it go to waste. This meme is a good explanation about how these past 6 weeks have gone.

    Though I must admit, I have grown more comfortable with the yellow screen of Django errors, so familiar that my chrome web browser has decided it should be one of my home screen pages. I either have a very limited browsing history, or I have spent more time debugging then I wish to admit.

     I would love to say that these past six weeks have been smooth sailing, that I did not face the inevitable second guessing, and small mental breakdowns that comes with programs like these. I was unprepared for the total loss of time I would experience, I eat all three meals of my day at school, I have even been tempted to sleep in one of our bean bags, and I am positive I am going to cause a tea shortage. But I would not trade the time spent at rocket with anything in the world, and the friends I have made at school are the best part. Its just a bonus they happen to understand what coding really is, and do not judge me for basically spending my days trying to communicate with my computer.

    This first post I am going to keep short and rambled, because I believe in this concept of sleep. But even in my sleep I can not escape the grasps of my programs.

      I think I will keep my blog updated with many memes, a blog about coding might bring all the  coders to the yard, but the memes keep them coming back.