Forem: ash🇨🇦

First client contract - Need Help with Real Estate with RETs

ash🇨🇦 — Mon, 30 Sep 2019 18:48:30 +0000

How do I integrate RETs mls listings into my solution?

I'm doing a contract for a Real-Estate company and basically have to integrate a solution to list all MLS real estate listings on a page. There are other specs as well but they aren't an issue. I'm building with RoR (with pg) and deploying with AWS elastic beanstalk (EC2).

Initially I thought I was going to use a simple API endpoint which had some json data but this isn't available in the Real Estate industry. Instead I had to access the IDX solutions through which I have to use RETs, a database for MLS listings. However I'm so confused as to how I should integrate RETs and what it exactly is?

If there are any Devs with Real Estate experience, can you please help me understand how to integrate this?

I'm currently looking at alternatives like https://simplyrets.com/

Thanks in Advance.

AWS Static Website Hosting for beginners Part 2 Setting up a Domain

ash🇨🇦 — Mon, 16 Sep 2019 21:21:25 +0000

Register a Domain - Static Website Hosting Part 2

This is part 2 of Static Website Hosting for beginners. In the first section we setup a basic website with a AWS generated url. In this section we will replace that URL with our own domain.

Checkout Part 1 if you haven't done so.

AWS Static Website Hosting for beginners Part 1

ash🇨🇦 for ExamPro ・ May 19 '19

#beginners #aws #career #webdev

To host your static site on AWS, the first thing you need to do is register a domain for it. This can be done in multiple different ways. "Registering" a domain basically means claiming ownership of it for a specified period of time.

The bucket names we use must match the names of the website that we are going to be hosting. For example, to host your example.com website on Amazon S3, you would create a bucket named example.com. To host a website under www.example.com, you would name the bucket www.example.com.

In the AWS console, dropdown the 'services' table and navigate to route 53

If you don't already have a domain name you can purchase one directly from here
Type in a domain name of your choice and choose a TLD (top-level-domain) e.g .com
Check to view availability of the domain
Different TLD's have different costs associated with them e.g .com vs .ninja

Once you've found an available domain that you like, add it to your Route 53 cart and click "Continue"
Follow the next few steps and complete your purchase of the domain.

It should now be listed in your route 53 console list

Alternative: Importing from a third party domain-provider

If you were like me and got a domain from freenom.com or any other third party domain-provider, do the following:

Go to Route 53 and select "create a new hosted zone"
In the form field, enter the domain name you own e.g "yourDomain.com"
Leave the "Type" as public and create

Open up your new hosted zone and copy your Name server values

Paste your name server values within the domain providers custom name server settings so that the DNS resolution can be passed in AWS hosted zone

Create a Wildcard Certificate

We now need to setup a SSL certificate so that our domain is secure and verified

In the AWS console search for "ACM", stands for: AWS Certificate Manager. This is where all your SSL certificates are going to be maintained.

Click "Request a Certificate"

On the subsequent page select "Request a Public Certificate"

In the domain name text field, we are going to enter a wildcard domain. Enter your newly purchased domain name but add

*.

at the front e.g *.silver-stack-solutions.com
Wildcards handle subdomains for you. This means that

www.

will be handled as part of the wildcard for our domain
Tip: Using the "add another domain" button, you can add protect multiple domain addresses to a single ACM. Wildcards only protect your domain name and any prefix placed before it. They don'y actually protect the naked domain e.g silver-stack-solutions.com is not protected but www.silver-stack-solutions.com is. We will get more in to this concept later on in the tutorial series, specifically when we handle redirects.

Click "Next"

You will now be on a page showing two options. Checkmark the "DNS validation"

Carry on and click "Review"

On the last set-up page click "Confirm and Request" after skimming over your details

You should now have your wildcard domain listed in your ACM console that is pending validation

Verify Ownership of Domain Certificate

From your ACM console select your certificate and expand it by clicking on the dropdown arrow
You should see a big blue button saying "Create Record in Route 53", click it
- Each record contains information about how you want to route traffic for one domain (such as example.com) or subdomain (such as www.example.com or test.example.com). Records are stored in the hosted zone for your domain.

A modal will open showing you details of your DNS record for domain validation
Simply click "Create"

Wait patiently as this may take a little while
By the end of it, you should have an issued ACM for your domain. It should be listed in your ACM console as status: "issued"
Repeat the process a second time and issue a second ACM except this time, don't make it a wildcard, just use the bare naked domain i.e yourDomain.com (or if you have already don so by adding another domain to your existing certificate, skip this step)

Having the wildcard ACM certificate is essential for our next step in CloudFront distribution

Create a CloudFront Distribution

This will do two things: make your website load fast anywhere in the world and allow you to use HTTPS, the secure version of HTTP. Just like S3 is organised into "buckets", CloudFront is organised into "distributions". You need to create a distribution for your website and point it at your S3 bucket, so that it can use the contents of your S3 bucket.

Navigate to CloudFront

Click on the "Create Distribution" button to get started, and select that you want a Web distribution, instead of RTMP.

You should now see a long form with multiple configuration options.
Select the dropdown for "Origin Domain Name".
You should see your S3 buckets listed. Do NOT select any of these

Instead you will need to copy the endpoint of your S3 bucket, located in the S3 properties tab under static web hosting

Find the endpoint URL in the "Static Website Hosting" section of the properties and paste that into the "Origin Default Name" field. Remove the "http://" from the front of the endpoint. The origin ID text field will auto generate your S3 bucket name in the text field.
In the "Viewer protocol policy" options, checkmark the "Redirect HTTP to HTTPS"

The next field we need to fill out is "Alternate Domain Names (CNAMEs)"
Enter your domain name into the CNAME field, for example, "www.ashwinkhanna.tk"
This should match your bucket name
Below the CNAME we need to link it with the appropriate ACM certificate, checkmark the "Custom SSL certificate" option
A dropdown with all your ACM certificates will be listed, choose the appropriate certificate. If your CNAME has www. then you should select the wildcard ACM we generated in the last section.
In the dropdown text field, select your newly created public wildcard certificate

Scroll further down the form and find the "Default Root Object" field and enter "index.html"
Click "Create Distribution"

Go back to your CloudFront console. You should now see the distribution status in progress. The deployment can take anywhere from 5 to 20 mins, just be patient.

Once the progress is completed, the distribution status should be "enabled

Point Domain to CloudFront

Navigate back to Route 53 and select hosted zone

We need to add a new record set to point to CloudFront
Click on "Create Record Set"

In the "Name" text field set our domain with prefix www
In the "Type" dropdown field select "A-iPv4 address"
There's an "Alias" field below with two options
- Select "Yes"
- This will cause the "Alias Target" field to appear
Over here we need to paste in the cloudfront domain name, it will end with a .net
- To find the cloudfront domain name, go to the CloudFront console and click into your newly listed distribution, you should be taken to the details page. Copy your domain name field from here and paste it into the"Alias target"

"Create" the new record

This may take a little while to create because DNS uses a technique called caching to avoid overloading the system
Enter in your domain into your web browser
It should open up your website with "https://" at the start of the URL

Notice that the URL is now our domain and not the old one generated for us by AWS

Conclusion

I hope this tutorial was helpful to readers and expanded on the content of my first tutorial. In future I plan to also add tutorials on file transfer protocols to upload files to S3 using the AWS cli and Cloudfront cache invalidation.

AWS Static Website Hosting for beginners Part 1

ash🇨🇦 — Sun, 19 May 2019 17:37:47 +0000

Here's a quick guide to setup up a static website using AWS simple storage service (S3). This is the first part of a longer tutorial I'm working on (check it out at in the exampro workshops section.

By the end of this short guide, you'll be set up with a live website that is referenced by an amazon generated URL.

A great application for this tutorial is using it as a professional web resume. If you're job seeking in the webdev market, this is a great way to demonstrate to employers that you have exposure to AWS services. If you're into AWS you can use this guide as a hands-on lab to familiarise yourself with the console and build confidence.

Creating an S3 bucket

Our first task in creating a static website is to set-up our S3 bucket. We can use the bucket to store files, images, audio recordings, etc. but in this tutorial we will use it to store our websites project files and then render them into the browser.

Have a static template on hand. I've picked the following. Make sure you have an index.html and an error.html file in the root directory. Add some type of error message into the error.html file.

Navigate to the S3 management console
Click on the services dropdown tab in the top left corner

Type S3 into the search bar and select it from the search results

This should now open the S3 console page:

Go ahead and “Create bucket”

Enter a bucket name. This will be used as your unique URL generated by AWS. Each bucket name must be unique because this is the URL associated with your website.
Add "www." to the beginning and ".com" (or whatever the suffix of your domain is) to the end of your bucket name.

Leave the configure options blank and hit "Next"

Uncheck both options under “Manage public bucket policies”
Leave the ACL (access control list) options check marked

Your review page now looks like this. Hit “Create Bucket”

You will now have your domain/ bucket name listed under your S3 bucket list.

Enable Static Web Hosting

We have our bucket listed in our S3 console. Notice that it is not set to public. We have to alter the bucket permissions and properties to make this happen.

Click into your newly created bucket name which should now be listed under S3 buckets and select the properties tab

Click on the “Static website hosting” option which at the moment is disabled, we need to enable it

A modal should open after selecting “Static website hosting”.
- Checkmark the “Use this bucket to host a website” option.
- Then fill in the index and error inputs with “index.html” and "error.html"
- Save the changes

In your overview properties tab, it should now show "Static website hosting" as enabled
- We have officially set-up our bucket for static web hosting
- Next we need to set up “permissions” to allow read access to our files

Bucket policy

Select the “Permissions” tab, located beside properties.
Then within permissions, choose the Bucket policy tab.

Within the bucket policy editor, paste the following lines of code

{
  "Version": "2012-10-17",
  "Statement": [
  {
    "Sid": "AllowPublicReadAccess",
    "Effect": "Allow",
    "Principal": "*",
    "Action": [
    "s3:GetObject"
    ],
    "Resource": [
    "arn:aws:s3:::www.silver-stack-solutions.com/*"
    ]
  }
  ]
}

Replace “www.silver-stack-solutions.com” with your own bucket name and "Save"

It’s normal that you get a warning message: “You’ve given public access to your bucket”. This allows read access to our index.html file
Navigate back to the S3 console. Your AWS S3 console should list your bucket as "Public" now

Upload content

Click back into your S3 bucket and select the “upload option”

Drag and drop your project files and upload them

Once finished, your project files should be in your bucket

View website

We've completed setting up our bucket and giving it permissions. We can now access our content from the web browser.

Navigate into your S3 bucket
- Click into your index.html file

Notice this URL, it is the endpoint for your static website. Go ahead and click into it.

The object URL is affiliated to your bucket name but generated as an AWS resource URL. We can change this by importing a pre-purchased domain name or buying one directly from aws route53 (not covered here).
If everything went well, you should be able to view your newly created website. If you encountered any problems, you will be directed to the error.html file.

Conclusion

I hope this tutorial was helpful to readers. It's my first tutorial post to dev.to so if you followed along let me know how I did.

If you liked this article, check out another ExamPro article by our UX Engineer Karan. It's also his first post so share some encouragement:

AWS Quickly Build Architectural Diagrams on Adobe XD

Karan Balaji 🇨🇦 for ExamPro ・ May 20 '19

#aws #tutorial #productivity #webdev

Part 2 is about setting up your own Domain

AWS Static Website Hosting for beginners Part 2 Setting up a Domain

ash🇨🇦 for ExamPro ・ Sep 16 '19

#beginners #aws #career #webdev

6 months after graduating Lighthouse Labs, a reflection on full stack developer bootcamp

ash🇨🇦 — Thu, 11 Apr 2019 17:45:23 +0000

Why did I want to join?

A little about myself, I came from a non-tech background. I didn't know basic html/css, nor did I know how to operate a terminal. I had experience in the start-up industry and mostly in business development. Like a lot of people, I wanted a career change and the ability to innovate all my cool start-up ideas.

At the time, I was working overseas and came to Toronto specifically to take this course and find myself a relevant job in full-stack web development. I found it to be a challenging 14 week course that tested my ability to learn and implement.

Reality vs Expectation

Before my first lecture, I was expected to have knowledge of github (version control) and basic html/css and Javascript. The bottom line is that you need to be able to teach yourself or you won't be getting much value from a bootcamp.

Many of the things that I learnt over the course of 14 weeks made me feel competent as someone who can code and build a web app. I was introduced to postgres, react and express which quickly became my goto tools for full-stack development.

However as soon I graduated and started job seeking and going through coding challenges, everything changed. It was soul crushing searching for a job where you compete against university certified engineers or developers with years of experience. Every job had vastly different tech stacks and my goto tools started becoming rusty as I had to allocate time in learning the technologies relevant for the job.

The biggest shock to me though was my lack of competency in devops and the need for it at most full-stack jobs. A lot of what I had learned at bootcamp was geared towards building apps for the development environment but I wasn't taught enough to actually be able to deliver and maintain a scalable and production level solution. I had limited exposure to both heroku and aws, which I feel in hindsight are fundamentals.

Getting a job vs reality

I was told that I would be getting a job within 3 months of graduating. Didn't happen that way. Just because you know how things work doesn't make you qualified to do the job. 14 weeks doesn't make you a web developer, it's an unrealistic target for most people.

I was put in touch with multiple employers but most of the time the issues were very similar. The employers had unrealistic expectations from bootcamp grads. I remember I was once sent for an interview with a company that had a "wheel of fortune" type app. The problem was that they weren't even interested in hiring a web developer, they wanted someone for IOS. So there was a mismatch in networking which was super frustrating at times.

Most of the jobs that I applied for outside the bootcamp network, felt like I was punching well above my weight. One such example was when I applied and got interviewed by IBM, hardest coding interview I did, they ended up going for an engineering grad for the full-stack position. I would say of the 19 people who were part of my bootcamp class, 4 dropped out, 3 got jobs right after graduating, the rest had to really struggle to find their feet and not everyone got a job in full-stack development.

Was it worth it?

Absolutely! It cost me time and money ($8K CAD) but I did get enough knowledge and hands on experience to get involved in the industry.

The networking aspect of the bootcamp was excellent despite mismatching me most of the time. I ended up leveraging the network I built at Lighthouse Labs and continue to rely on it today. Through the bootcamps network, I ended up meeting a ton of interesting people and finally got working for ExamPro, in a very cool hybrid role.

Those devops skills that I lacked in bootcamp are precisely what I get to work on and learn daily. 6 months after graduating, I realised most of what you learn will be through work experience and networking. The benefit of a bootcamp is only to help get you a foot in the door.