@theartofmadeline
The Stonewall Inn
Game Changer & Make Some Noise
macklin celebrini has autism
2025 on Tumblr: Trends That Defined the Year
noise dept.
❣ Chile in a Photography ❣
Kiana Khansmith
bliss lane
Phantogram Three
izzy's playlists!
Show & Tell
Sweet Seals For You, Always
Aqua Utopia｜海の底で記憶を紡ぐ
almost home
Keni
The Bright Sessions
The Bowery Presents
art blog(derogatory)
I'd rather be in outer space 🛸
seen from Malaysia
seen from United States
seen from Thailand
seen from United States
seen from Australia
seen from Germany
seen from United States
seen from Switzerland
seen from Germany
seen from Austria
seen from Kazakhstan
seen from Russia
seen from Türkiye
seen from Australia
seen from United States
seen from Malaysia
seen from Russia
seen from France
seen from Singapore
seen from Russia
@app-academy-kyungmin
Silly API
A confusing API can make someone a confused developer. In the development world, of course it's developers' fault for being silly. I wish developers think more like designers and understand that it's the silly API, not the silly people.
Week 9, Day 4: Making of Passwordlet
passwordlet.com is finally out to the world!
It was a solid two-week journey of clearing a series of hurdles. Along the way, I gained some valuable insights around some of the most interesting topics – security, cookies, and encryption. Here are some highlights:
Cross-Domain AJAX calls
Creating a bookmarklet that loads JavaScript code introduced a lot of challenges. In the beginning, I stored all of my JavaScript code directly in the bookmarklet, but later I moved all of my code to my app as it grew larger. The only unforeseen consequence was I could no longer test it locally, as most sites don't allow cross-domain calls from HTTP. I pushed my code to Heroku, and I was able to get the SSL ("https://") connection.
CORS
Even with the SSL connection, I got a "HTTP OPTIONS request 404 (Not Found)" error. I learned that cross-site requests make HTTP OPTIONS request for every PUT/GET request. 'rake-cors' gem allowed my app to accept all origins for all request types.
I spent most time fighting agains the "No 'Access-Control-Allow-Origin' header..." error. Even if my app accepted all origins, the sites wouldn't let me make ajax calls to other domains. The trick I found was to use jsonp data type when making ajax calls.
Password encryption
I was really scared about this part, so I deferred encrypting my passwords until I got the auto-login to work. After much research, I later found that Ruby actually supports OpenSSL and it was actually pretty straight-forward. The only tricky part was that I had to convert the encrypted passwords to UTF-8 to save them to Heroku database.
Finding forms
To log in to the user's account behind the scenes, I used a ruby gem called Mechanize, which automates user behavior as an agency. My form finding logic is pretty rudimentary as of now.
While not perfect, it works on some of the most popular sites like Twitter, Instagram, IFTTT, and NYT. Check it out and enjoy the auto-login!
Passwordlet demo
Yay, it works!!
Week 8, Day 1: WebSockets, Cookies
Chat app
Today we created a simple chat app using socket.io and node.js. Initially, I didn't really understand what web socket does and mindlessly followed the instructions and examples from the socket.io website. The server-side programming was not so inspiring until we actually saw our chat messages appearing real time from different devices. It turned out that it was actually pretty cool! At the end of the day, I got a better sense of what WebSockets do and how to use them. Along with backbone.js, socket.io is another event-based framework that makes the web feel snappier.
Passwordlet
I decided to start my final project with the most scary part – logging in the user using cookies. I didn't really have a clear idea of log in users using cookies, so I started researching more about cookies and a gem called mechanize.
mechanize is a gem that clicks around and fills out forms as an agency, similar to capybara (which is purely used for testing). Using mechanize, I wrote a method that logs in to a website on behalf of the user to return a set of cookies. Then I tested this by going to a website, setting the new cookies in the browser console, then reloading the page to see myself logged in.
Setting cookies in the browser was actually very tricky, as it turned out that it has a very strict syntax:
First the name-value pair ('ppkcookie1=testcookie')
then a semicolon and a space
then the expiry date in the correct format ('expires=Thu, 2 Aug 2001 20:47:11 UTC')
again a semicolon and a space
then the path (path=/)
At first, I followed this guidelines very loosely, and it didn't work. After A TON of trial and errors, I finally saw myself magically logging in! Yay for committing my first code for my final project today :)
Week 7, Day 7: Final project proposals
The Final Project week finally has started!
The first challenge of the project was to decide what to work on. I had some ideas for my final projects, but apparently all of my ideas belong to their DON'T DO list. Our instructors didn't want us to design anything from scratch or work on more than one project. While our instructors are probably right, I decided to ignore their advice. I will be designing on my own and potentially work on two projects. I just can't give up product design. It's the most fun part of the app development!
So here are my two proposals:
Passwordlet
Nomgram
Even if I can actually work on both of them, I will have to start with one of them. Which one should I work on first?
Week 7, Day 3: Backbone on Rails (Part 2)
Trying to learn Backbone within a couple of days has definitely been a challenging experience. I continued to work on making my super AJAX-y Journal app. The app can now create, read, update, delete posts without page refresh and respond to various events. Getting it to work (while learning Backbone at the same time) was painful, but seeing it working smoothly was pretty cool.
I'm still working on creating comments on a post, which is much trickier than simply creating a post. Ned demonstrated how to override Backbone's parse and toJSON methods to correctly pass the nested parameters to the Rails controller, but doing it myself was not as easy as it seemed.
This week is the final lecture week. By the end of this week, we should be all capable of working on final projects on our own. It's a little scary, but it will be an interesting and worthwhile journey.
Demo of Journal app using Backbone.js
Week 7, Day 2: Backbone on Rails (Part 1)
Today is our first day to deep dive into Backbone. Ned provided us with a great demo of building Backbone on Rails from scratch. We learned how to override default click events and routers, so that we can gain more control over them. We learned how to create and delete posts and navigate between pages all via AJAX. We learned how to pass data all the way from Rails Controller to Backbone View to render it asynchronously.
My rough (possibly slightly incorrect) understanding of Backbone so far:
By delegating Rails to be purely responsible for handling the data to and from the database, Backbone can focus on providing the "buttery smooth" user experience in the browser (well, it's my subjective view on its purpose). I'm still getting used to Backbone's MVC model, but I can already tell Backbone is quickly becoming one of my favorite tools.
Try Google Cloud Console
I'm going to post a shameless advertising here.
About a year ago, I spent over two months redesigning the API & Authentication flow. Finally, the brand new Cloud Console is fully available to the public!
The old API Access page didn't make a lot of sense to most people at a first glance. Developers would mindlessly follow the documentation step by step to "get the job done". From the user testing, we confirmed that they didn't really understand how it works. After painstakingly going through the existing flow and use cases, we came up with a simpler UI flow that would guide users to get the right credential for their needs. I put a lot of effort into it, trying to find the right mental model and flesh out the details with some amazing front-end engineers.
@googledevs Been using it for the past month or two. Much, much improved from the old interface.
— Japhy (@japhychron) October 29, 2013
It still has a long way to go, but its mission is more than a facelift. With much less time spent on getting access to APIs, developers can spend more time actually using the API. If you are using or considering using Google APIs, give it a shot and let me know what you think.
Week 7, Day 1: JavaScript MVC
Today we attempted to make a full JavaScript MVC app from scratch. I was excited about the fact that we would have implemented a photo tagging app by the end of the day. However, with our rudimentary understanding on JavaScript, implementing a full JavaScript MVC within a day almost sounded like a joke at the same time. Basically, we were trying to make a Backbone app without using Backbone. We were learning it the hard way first, as always.
Not surprisingly, we spent most of our time under the app/javascript folder, writing JavaScript code. We learned how to use the _.extend method and JST to dynamically generate DOMs and attach event listeners. We also learned how to fetch and create data from the JavaScript Model. We ran into many little problems and got confused by many new concepts. By the end of the day, we managed to display a list of photos, after many trial and errors. Yep, that simple thing was our biggest achievement of the day.
It would have been much easier to do this in Ruby on Rails, but it won't make asynchronous calls. JavaScript allows us to gain more control over front-end user experience and render things faster, which is really awesome. Tomorrow we will learn about Backbone.js, which I'm a little scared about. It may take time to master it, but it'll be worth it!!
Week 6, Day 5: AJAX
Today we learned how to make AJAX calls on form submission by using jQuery in our Rails app. Our apps can now post messages without having to refresh the entire page!
These services enabled us to create our responsive form page:
jQuery $.ajax()
serializeJSON()
underscore template
Since we finished our exercise early, we also covered other concepts like, error handling on AJAX failure, improving the UI layout.
Week 6, Day 4: More games (Tic Tac Toe, Towers of Hanoi, and Snake)
Times goes so quickly. I mean, really really quickly. Only a couple of weeks ago, I was still trying to understand how associations work in Rails, far from claiming myself as a developer. Today, I found myself building 3 mini online games like it's no big deal.
Using existing logics for Tic Tac Toe and Towers of Hanoi, we focused on building the front-end in jQuery and CSS. We learned how to load JS files correctly, communicate the data back and forth between the UI and the server side. In our JS file, we generated simple divs, attached data-* attributes, then displayed the data within each element. Thanks to jQuery's event handlers, defining onclick behaviors was a breeze.
We then built the Snake game from scratch. After defining classes and functions for Snake, Board, and Game, we displayed our snake and randomly generated apples every 100 moves on the board. Then, we added key bindings so the snake can make turns and collision check functions so the snake can grow each time it eats the apple.
I had some ideas that I wanted to try to make the game more interesting, but unfortunately we ran out of time. Having built fake prototypes in jQuery in the past, seeing an app that actually works was pretty exciting and awesome.
Week 6, Day 3: Asteroids
I had a lot of fun creating the Asteroids game in JavaScript and HTML5 canvas today.
I found it really helpful to have learned Ruby in the beginning of the program. The OOP concepts like inheritance, class/instance methods, and namespacing that we learned from Ruby all came together as we implemented an application in JavaScript. Implementing objected-oriented JavaScript was simply a matter of learning new syntax.
Making Asteroids required some serious physics and math knowledge, which I definitely needed some help with. However, I found myself staying late figuring out other HTML canvas functionalities to make the game work and look better. It's one of the few the moments during App Academy when I actually got serious about finishing an app in a day. It's a real app!
Week 6, Day 1: Intro to JavaScript
Our TA started this morning with an interesting story of how JavaScript was made within 10 days. I was like, no wonder JavaScript has bad usability! Yet, JavaScript is pretty much the only language that's designed for web browsers up to now. It's still hard to believe that a language with such bad usability is the most popular key ingredient for modern applications.
My first impression after playing with JavaScript is that it violates most of the usability heuristics. It doesn't throw errors when it should. When it does, the errors aren't so descriptive. It doesn't behave in a way that developers expect. Its behavior is inconsistent from other programming languages. It doesn't prevent developers from producing verbose and error-prone codes. It lacks documentation on best practices. Here are some absurd things about JavaScript that I learned today:
Monkey patching #1: Class objects
var cat = function(name) {}; // OR function Cat (name) {};
Monkey patching #2: Instance methods
Cat.prototype.purr = function () {};
The scope of "this" depends on the context. A common trick around this is:
var that = this;
Adding two Arrays returns String. To get what's actually expected, use concat() or push() instead. Note that concat() doesn't modify the original array, whereas push() does.
[1] + [2] // returns '12'
If you declare a variable after assigning it, it will still work. What's happening is that it hoists all declarations to the top.
a = [1, 2]; var a = [];
I'm still a big fan of Ruby, but unfortunately it's not for browsers. Once I get the hang of JavaScript, I'm looking forward to trying out modern JS frameworks like underscorejs, requirejs, which I believe is design to solve some of these problems.
Week 5, Day 6: Startup School
I was lucky enough to attend Startup School by Y Combinator. It was surreal to feel the entrepreneurial vibe and be among those highly passionate and driven people.
The talks were amazing. Each speaker gave inspiring advice to young entrepreneurs, drawing insights from their own experiences. Some of them were emotional, some of them were spiritual, but one thing they all had in common was they all had the passion and dedication to solve difficult problems. I tried to jot down some highlights here:
Phil Libin, Evernote Founder
The initial VC pitch went like, "So our app lets people write some stuff.. and it's free. By the way, we have a ton of strong competitors." It didn't go very well. I had to make an adult decision to focus on one thing - making a product I would love to use myself.
Don't be clever on the investment structure. Be clever on one thing - your idea. They won't look at you until you become significant.
Things were simple when the only job was to raise money. It's liberating to be allowed to fail. When it became a real company, it got hard. Things don't get easier. It's not fun day to day, but it's vastly satisfying and fun month to month.
So build it for yourself and make something great – It wouldn't have been a great advise 5 years ago, but it is now.
Dan Siroker, Optimizely Founder
The fundamental algorithm of all the greatest companies is continuous improvement. Take feedback and make continuous improvement.
Your job as an entrepreneur is to write your own algorithm, rather than to execute an existing algorithm.
Ron Conway, SV Angel Partner
Product focus is crucial. We invest in people. I did not invested in Twitter because of the idea. I invested in Ev's good soul.
Founders biggest fundraising mistake - focusing on valuation. Instead, find an investor who can help you get a million more users by improving the product quality.
Hiring: You have to be decisive. Are you a team builder or leader? Can you manage 1,000 people? Recognizing deficiency and building a team around that is important.
Trend: Companies are move to the city. The IP is no longer around algorithms. Now it's around design and user interface.
Chris Dixon, Hunch & SiteAdvisor Founder
The winning startups are the ones with good ideas that look like bad ideas. Powerful people often dismiss great startup products as toys.
You need to know a secret – something you believe that no one else does.
Chase Adam, Watsi Founder
(Watsi is YC's first non-profit organization. His talk was phenomenal and most heartfelt among all.)
With non profits, it’s hard to know whether you are succeeding or failing. The problem is that it's hard to get feedback from beneficiaries in the developing countries (language barriers, etc.). So I created Watsi to be 100% transparent, 100% donation.
VC pitches for for-profit companies are simple. Instead of returns, Watsi is selling vision.
Find something to work on that you care about more than yourself.
Week 5, Day 4: Reddit On Rails
Today was our second Test Driven Development day at App Academy. Since our first encounter of TDD a couple weeks ago, we brushed up our RSpec skills again. Rather than rushing to complete the entire application, we chose to think through every step and made sure we understood it. It was one of the few days when I felt more relaxed than usual, but I actually learned some useful things with my pair partner along the way.
We spent so much time trying to figure out why one of our tests was passing when it was supposed to fail at first. We wanted to test an invalid case to be not_to be_valid, but it returned an invalid state for a different reason. The issue was that our association wasn't set up correctly. So we revisited our models and fixed the associations. We added the "inverse_of" property, along with the presence validations on the associations instead of foreign keys. When we finally saw our test fail, we couldn't have been happier!
Using gems like factory_girl_rails, faker, and shoulda made testing a little bit easier.
We encountered some specific syntax requirements of RSpec. For example, when comparing return values, we should use either eql or == instead of eq:
expect(FactoryGirl.create(:user, :password => "password") .password_digest) == "password"
Many people don't enjoy writing tests because it feels tedious. I also felt tired of it after spending a full day on writing tests. However, I believe it's a good investment to make my future life easier as a developer. Hopefully, it'll become easier and more enjoyable as I get more used to RSpec syntax.
Week 5, Day 5: More on TDD & Rails
Today was another day of practicing TDD. After a full day of practice yesterday, writing RSpec specs felt much easier. This time, we spent more time on using capybara, which is a cool gem that automates visiting pages and clicking things around. We also created spec helper methods, which made it our spec file much cleaner.
My pair partner already had a well-organized git repository, so he helped me with trying out other git functionalities, like branching and merging it back to master. Now that I got more familiar with using git, I'm starting to see the power of git and other command line interfaces.
After the two weeks of Rails curriculum, I find myself getting better at spotting errors and guessing reasons. Two weeks is definitely not enough to fully appreciate what Rails has to offer. I'd like to revisit some concepts, like associations and join tables, and better visualize what's going on behind the scenes. While I'm a bit sad to say goodbye to Ruby on Rails for a little while, I'm looking forward to getting my feel wet with JavaScript for the next two weeks!