Categories
Developement

Pay or Stay: A Salary Intelligence Tool

Pay or Stay is an idea I came up with as a quick and easy app to help me brush up on my development skills after returning from a one-month backpacking trip across Europe.

The idea was to create a salary intelligence app to help empower those who are considering moving to another city. It will be a tool to find out what you need to earn in the city you want to live in to maintain the same standard of living + more.

I just recently moved from New York to San Francisco. Before my move, I have spent countless hours researching cost of living, average salary, taxes and other things in multiple cities when I was deciding where to move. So I thought, why not build something beautiful that does it all for me with one click and share it with others?

There are already salary calculators out there, but I wanted to do more than just spitting out a number. I wanted to provide related salary information that can be helpful as well. I wanted to create a beautiful and visual one-page “report” that is both informative and easy to understand (kind of like those credit score trackers or Mint.com reports); something people can use to do research on different cities or for their negotiations.

This app was originally called “Needle in a Haystack”. After sharing my initial idea with a few friends, they came up with the name “Pay or Stay”.

I spent three days working on this app, including research, backend development, frontend design, deployment, and bug fixes. The final outcome was not as feature-ful as I had envisioned due to the lack of public data available. I was discouraged by the lack of data at first, but I ended up letting go of some of my ideas and pivoted the app (multiple times).

With some creative workarounds, Pay or Stay ended up being pretty close to what I envisioned. Using the Cost of Living Index, Pay or Stay calculates what salary you need to earn in the city you want to live in to maintain the same standard of living you currently have. I’ve also implemented some additional features and laid it out in simple and beautiful mobile-responsive dashboard.

Check it out here: payorstay.tonymai.net

If I ever come back to this app in the future, some of my desired improvements will be:

  • Compare your salary to average salaries for specific job title and locations
  • Where you stand in the salary distribution for your job title and location
  • Historical salary data for specific job title and locations
  • How your salary compares to minimum wage for all locations
  • Refine calculations based on state and city taxes
  • More current Cost of Living index
  • More data points to cover more locations (both in the US and internationally)
  • Display sample pre-filled budgeting templates for both locations and calculate how much average disposable vs. discretionary income you will have
Categories
Dev Bootcamp

Wrapping up at DBC with “Bring Home To Mom”

It’s been an amazing 9 weeks at Dev Bootcamp. I’ve learn so much more than I thought I would in 9 weeks, and more importantly, made many new connections and friends. Each one of my cohortmates will do big things.

During the last week of DBC, we pitched ideas to the entire school and the best pitches were selected to become final projects. I couldn’t ask for a better team (Jonathan Berk, Sofie Garden, Kevin Ceballos, and me). We were all motivated, self-driven, and always the last to leave the building. I knew I could rely on each one of my teammates to push the project forward. In just 7 days, we’ve packed SO many features into our app while still keeping it simple and easy to use on the frontend.

Some of the technologies/frameworks we used include:

  • Ruby on Rails
  • PostgreSQL
  • Javascript
  • JQuery
  • AJAX
  • handlebars.js
  • Faye messaging system
  • HTML5
  • CSS3
  • Responsive Grid System
  • Stripe API
  • Twilio API
  • Cloudinary API
  • Rotten Tomatoes API
  • OMDB API

Some of the features include:

  • Create child profiles
  • Smart matching system based on filters and interests
  • Autocomplete
  • Dates dashboard
  • Design a date page
  • Choose a date experience
  • Real-time messaging system
  • Pre-fund dates
  • Text notifications
  • Responsive design
  • Asynchronous updates for best user experience and minimal page reloads

And finally, here is Bring Home To Mom (51min-104min):

I will miss you guys!

Before:

2015-04-16 18.10.32

After:

2015-04-23 04.10.08

Team Bring Home To Mom:

2015-04-24 12.19.35

Categories
Dev Bootcamp

Introducing: Nearby Meetups

I just finished Phase 2 of Dev Bootcamp! It’s crazy how much I learned in the past 6 weeks. Git, Ruby, Sinatra, Javascript, AJAX, OAuth… all these terms were foreign to much just a few months ago.

I’m just writing here to share a simple Sinatra app that I built for my personal project during Phase 2.

“Nearby Meetups” started out as a fun project that would help me solidify EVERYTHING that I’ve learned during my first 6 weeks of DBC as well as learning more technologies.

I like Meetup.com, but the user interface didn’t appeal to me, so I rarely used it. I like to see things visually – where the events are located, how popular they are, when they are taking place, etc. – all at one glance.

Enter “Nearby Meetups” (www.nearbymeetups.com), a web app that utilizes the data from Meetup.com and visually displays them in a way that I would like them to. This was originally just a project that I did to solidify my learning, but after presenting it to everyone at DBC, I’ve received a lot of positive feedback and request to open it up to the public so that they can use it, too.

I am open to all kinds of feedback, issues, suggestions, and feature requests – anything that will help improve this app and make it easier for you to use.

Anyway, I’m ready to go onto Phase 3 and finally learn Rails on my last few weeks here!

Categories
Dev Bootcamp

How To Ask Questions That Get Good Answers

Have you ever asked a question and received zero response?

I have done a lot of coding-related research, which brings me to Stack Overflow very often. After a while, I started to notice a lot questions that aren’t answered or are even locked because it is not specific enough or does not follow the question guidelines.

Asking a good question doesn’t strike me as being that hard, but it seems like bad questions pop up quite often.

Here are some tips on how to write a good question. This article is specific to coding-related questions, but can also be applied to any type of questions.

Research

Before you post your question, do your own research. Take a look at other people’s questions that are similar to yours. Chances are, there are other people before you that ran across the same problem and received the necessary answers. When you do post your question, cite related questions, even if it does not answer your question. This helps others identify how your question is different.

Title

Be specific with your title. Describe what your problem is in one line. Ask in the form of a question if possible (and it often is possible). People are busy and respond to questions out of their good will. When looking at postings, they will see a long list of questions. If your title is generic, it will not stand out and will get overlooked. Specific questions that state exactly what the problem is will stand out and catch their attention. Also, use tags to label your questions.

Content

Explain your question. It should include all of these pieces:

  • What you are trying to accomplish. What should your code do?
  • What is happening? What is it doing instead?
  • What you have already tried. What came up in your research? This shows others that you’ve put in time and effort into trying to resolve the problem yourself and are not just leeching for information, which will make them more willing to help you.
  • What your environment is like. Be as informative as possible (language, platform, operating system, or anything that is relevant).
  • Steps to reproduce your problem. Include the specific part of the code that is causing the problem or not doing what you want it to do. Only include enough code for them to reproduce the problem. Anything else is irrelevant. Big pieces of code will make people not want to look at it.
  • Also include what you are trying to achieve in the grand scheme of things. Others may have insight on how to better accomplish what you’re trying to do in an easier and more efficient way, which may even render your problem or question irrelevant.

Proofread

Make sure that your post has correct spelling, grammar, and punctuations. It doesn’t have to be perfect, but it should sound like you are educated. Format your question so that it is easy to read. Break it down into paragraphs if it is long and section off your code. Reread or have a friend read over your post and see if it makes sense to someone with no prior knowledge on what you are doing. Last, but certainly not least, make sure you actually state the question in your post. A lot of posts I see online are just long explanations or statements of what they’re doing with no real questions to be answered.

Feedback

Monitor your question and respond to feedback. Be opened to it. Provide clarification or more information when something is unclear to others. Do not take responses personally. Most people that respond to your questions are there to help.

That’s All, Folks

Hopefully, these tips will assist those in need write better questions that will generate good answers.

Do you have other tips on how to write good questions? Let me know!

 

This blog has been initially published on tonymai.github.io.

Categories
Dev Bootcamp

Using Jekyll to Generate Your Static Website

I have recently been using Github Pages to create my new personal project website. It was a good way for me to practice creating web pages from scratch with HTML, CSS, and even JavaScript. As a beginner, it was also a good way from me to practice using the terminal, git, committing, pushing, pulling, etc. I created simple index, about, contact, portfolio, and blog pages. For Dev Bootcamp, I’ve been writing 1-2 blogs a week on average and pushing it onto my GitHub Pages repository. All of these blog posts are on a separate web page following the same HTML blog post template.

There comes a point where I have too many blog posts to be able to maintain a website purely using HTML and CSS. Every time I want to make a change to the template, such as a link on the navigation menu bar or some text on the footer, I would have to go through each page and blog post and update the HTML in that page. It worked okay when I only have several web pages, but it got exponentially time-consuming as I built more and more pages.

Many websites are powered by a content management system (CMS), the most common one being WordPress, which is a great solution for creating a dynamic website. My own personal branding website is powered by WordPress. It can do just about anything you can think of. But my project website only needs to showcase my portfolio of projects and blogs. It will never need to use most of the functionality that a dynamic platform provides. WordPress would be an overkill.

Here comes Jeykll, a simple, static site generator that takes in a bunch of text and spits out a beautifully generated website. It gives me everything I need without all of the bulk that comes with a CMS platform. Jekyll allows me to easily create site-wide headers and footers without having to copy them across each and every page, which gets rid of the pain points I was describing earlier. It allows me to write content on web pages and blog posts with Textile and Markdown, so someone with no knowledge of HTML can still create a nice web pages.

Here is Jekyll’s definition on their website:

Jekyll is a simple, blog-aware, static site generator. It takes a template directory containing raw text files in various formats, runs it through a converter (like Markdown) and our Liquid renderer, and spits out a complete, ready-to-publish static website suitable for serving with your favorite web server. Jekyll also happens to be the engine behind GitHub Pages, which means you can use Jekyll to host your project’s page, blog, or website from GitHub’s servers for free.

Here are some advantages of using a static website as opposed to a dynamic website:

  • Simple – no database, no CMS, minimal
  • Fast – does not require server-side requests, so load time will be much quicker
  • Cheap – quick to develop, cheap to develop, cheap to host
  • Ease-of-Use – Since content is built with Markdown, so you can use whatever text editor you want to create and edit your web pages
  • Secure – less prone to risks, since there are no databases, CMS, PHP, etc.
  • Click here for more reasons from Site Point

Another great thing about Jeykll is that GitHub Pages is powered by Jekyll behind the scenes. Every time I push my website to GitHub Pages, it actually uses Jeykll to generate static HTML pages, so I don’t even need to do anything to make Jeykll work on GitHub. I just make the necessary changes to my Jekyll-powered website, push it to GitHub, and it automatically generates the static HTML and displays it on the web. This makes everything so easy. I can even point my domain name to my GitHub website and have fully-running website hosted for free.

The most difficult part of this process for me with the actual setting up of Jekyll on my local machine, so if you want to take Jeykll for a spin, here are some useful resources to start with:

After I got it set up, I spent quite a bit of time converting my previously hand-built HTML and CSS website into Jeykll’s simple text format. It was quite a pain, since I had a lot of pages to convert (I wish I started with Jeykll from the get go). But after the initial migration, I love it now. It gives me everything I need and nothing more. Automation where I want. Universal header and footer. Easy to change layouts. Simple pages created from plain text. Easy updates just by pushing it to GitHub; no databases, no FTP, etc.

If you’re running a simple website on WordPress and don’t take advantage of most of its features, consider using a static site generator such as Jeykll.

This blog has been initially published on tonymai.github.io.