DEV Community: Chris Power

Why I am switching from Vim to IntelliJ

Chris Power — Thu, 05 Nov 2020 14:10:27 +0000

From Vim	To IntelliJ

In the beginning, a love affair

For the last 10 years or so, I have been a die-hard Vim user. I was introduced to Vim on my first programming job. It was almost an instant connection for me. I fell in love with the minimalism of only needing a terminal to do work; and the power of stringing together commands, like words, to edit programs and text.

The love affair I have with Vim stuck with me throughout my career and remains strong to this very day. When I was a junior-level release engineer, working on small scripts, Vim was amazing. Later, working as a Ruby on Rails Engineer, Vim was still an amazing editor. Thoughtbot, Hashrocket, and countless other agencies, companies, and individuals contributed to the community (and cult) of Vim. That community pushed my knowledge, comfort, and understanding further and further.

Eventually, I was running tmux and Vim together in the terminal. With sufficient plugins and dotfiles, I was CRUISING through codebases. I could write tests, run them, refactor code, and run commands with absolute ease.

Vim and tmux... were so amazing

Old feelings fade

Lately, though, I have been feeling a little underwhelmed by Vim. Even with my sophisticated dotfiles, knowledge, and Plugin setup; something felt off. I started a new job working on a large typescript React project. Vim couldn't handle opening a TSX file larger than 50 lines without crashing.

Within the last few years, I tried my hand at programming mobile applications. Flutter and Dart -- although supported by an LSP -- was not running very well on my Vim setup. After giving Android Studio a shot with Flutter, it felt like a whole new world.

Android Studio with Flutter -- The tipping point

Android Studio was a game changer

All of a sudden, I had everything at my fingertips. Auto completion, Auto formatting, snippets, and documentation lookup was all set By Default. I actually understood the Flutter framework much better because Android Studio made deep framework code easy to debug, inspect, and explore. Not to mention, the Vim integration was fantastic. This was the best of both worlds. I had amazing editing, minimal configuration, and Vim keybindings!

When picking up a new language or framework in Vim, I would spend hours configuring plugins, dealing with linting, and looking up documentation. With and IDE like Android Studio, all of this came pre-built without any configuration.

Android Studio was something of a revelation for me. I began thinking to myself, "If this is so great for Flutter, wouldn't this be great for my other projects?".

Vim to VSCode to Webstorm to IntelliJ

I am now working almost exclusively on IntelliJ IDEA. It is the JetBrains defacto editor that includes plugins for almost anything:

Ruby on Rails
Ember
Angular
Typescript
React
The list literally goes on forever

Every project I work on -- like this Gatsby blog in React, my corporate Typescript React job, or my Ruby on Rails side projects -- All work within this one editor.

I had a brief stint with VSCode but, to me, it appeared to have the same flaws I disliked with Vim at the time. It was slow with large files, and it felt sluggish with complicated programs and complicated programming languages (like typescript and tsserver).

I also had a long affair with WebStorm, which was mostly great. I did; however, find it odd to be using an editor ONLY made for a few programs. If I wanted to run a Ruby on Rails app in Webstorm, I was SOL. I thought it was a little silly to run RubyMine, Webstorm, and Pycharm on one machine. If I wrote code in all three languages, shouldn't one editor be able to handle it?

Eventually I wound up running IntelliJ with plugins that handle any programming need I may have. And for now, I am very happy. There are, of course, many cons with IntelliJ. But I truly believe the Pros outweigh the Cons.

Vim and IntelliJ, a Pros and Cons list:

I still think Vim is a great editor and I love to break it out every once in a while. But I believe the pros of IntelliJ outweigh the cons of Vim at this point in my career. Here is an overview of my thought process.

Pros and Cons of Vim

When picking up a new language or framework in Vim, I would spend hours configuring plugins, dealing with linting, and looking up documentation.

Pros:

Minimalist. All you need is the terminal, and that is it. You don’t need to open multiple windows, Tmux and Vim together were awesome for this.
Gets you into the Flow: . Vim gets me into "The Flow" better than anything. I just need to move my fingers a bit, and I’m in/out of windows, buffers, splits, etc… I specifically remember smiling when I was coding with Vim, because it just felt so fun sometimes.
Extensible: It's been around forever, Thoughtbot, Hashrocket, and many community members contributed greatly to it.

Cons:

Very steep learning curve: Vim takes a long time to learn, and you’ll never stop learning it. This is not a problem with more experienced users like myself, but I thought it was worth mentioning.
Inconsistent Plugins: Quick, tell me the best plugin for auto-completion in Vim. ALE/Omnicomplete? YouCompleteMe? VimCompletesMe? DeoPlete? There is an insane number of plugins for any task you may have. And not all plugins play together. This has become slightly better with the emergence of LSPs; however, I constantly find myself playing with plugins to make things work better, only to dislike the setup and go for another mix of plugins later. Having dot files are nice, but when you switch computers/systems, you have to install pip3/python for some packages, node/npm/yarn for others, and for some, you’ll have to cd into the dir where its installed and run a makefile! (looking at you, YouCompleteMe)
Doesn’t always play nice with everything else: I have had countless configurations with Vim. Vim standalone, NeoVim, Vim with Tmux, and MacVim/GUIVim. They all have strengths and weaknesses, but there is always one thing in common, it doesn’t play very well with every computer system. Try to set up copy+paste on Vim on a Mac, done? Ok great! Now do it for Linux. There are so many workarounds and hacks to get everything to play well together. When you get it set up, its nice, but sometimes its rough. I find myself reading old blog posts to remember how I set up yank + paste on my system-wide clipboard over and over.
Isn’t very fun with complex codebases in complicated languages (like typescript): I remember starting a new job that used typescript, and there were a lot of engineers working on some really cool problems. After getting Vim/ ENV vars/ etc… all set up, I go to start woking in Vim and BAM, any file over 20 lines freezes and its incredibly slow to work with. Sure enough, my javascript parser/highlighting plugin (see my point above about plugins) was not efficient, and it was bogging down everything. So I had to settle for a lesser parser that performed better. A similar thing happens with prettier, eslint, and tsserver. If you need your code to be auto-fixed with these technologies, its blocks read/write. Even when your IO is blocked for only a short amount of time, it makes for a trudging, slow-as-molasses feeling when writing code.

Pros and Cons of IntelliJ

All of a sudden, I had everything at my fingertips. Auto completion, Auto formatting, snippets, and documentation lookup was all set By Default.

PROS:

Everything is pre-configured: You don’t have to worry about setting up tags, or YouCompleteMe, or NERDTree. I can’t tell you how many times I open a new project, perhaps in a different language, and everything works great out of the box. It's a total sigh of relief.
File watchers are powerful: There is a thing in IntelliJ called file watchers. You can set arbitrary tasks to run after you edit/save/type in a file. This can be super powerful when you have more advanced tasks you need to run in your codebase like: sorting imports, running specific eslint rules, or running rubocop after saving a file.
Everything plays nicely with your OS: I can’t tell you how many times I set up Vim and tmux on a new OS, like linux. I’ll run all my dot files, configure anything crazy I missed. Compile the plugins that need compilation. Fix any small issues that happen between Vim/tmux/linux (or Mac, whatever). Then I’m programming, and I have to copy+paste something, and BAM, I lose 4 hours configuring copy and paste correctly between Vim/tmux/
Complicated codebases and languages are handled easily: After using IntelliJ (or Webstorm), all my problems with my large Typescript codebase went away. Everything gets indexed, parsed, highlighted, and rendered correctly. There are very few hangups when working with complicated codebases, and the exceptions are usually much easier to deal with than with Vim.

CONS:

Complicated Interface: The interface to IntelliJ is somewhat, complicated. There are a lot of tools, dropdown menus, and configurations. This is definitely a daunting thing at first, but once you get used to it, its not a big problem at all.
Memory Usage: IntelliJ does eat up a bit of RAM on my machines. I believe this memory usage is worth it though. You're paying an upfront price to index, tag, and cache programs, so your editing experience is smooth as butter. VSCode and Vim (with plugins) only do this lazily; therefore, your programming experience with complicated projects becomes very awkward and slow over time.
Difficult configuration for some tasks: Again, this is something you get used to with time. Some configuration options with IntelliJ are less than ideal. For example, when setting up auto-formatting for eslint, you have to go through a couple hoops to set up a file watcher in IntelliJ. Once you understand this concept though, its fairly straightforward and easy to use with other tools.

In the end, I have decided that the pros for IntelliJ greatly outweigh the cons. I have been really happy with the platform and look forward to using it in the future.

If you've made it this far, congrats, you're really amazing. I wonder; though, are you feeling the same way I was? I am not sure I'm alone in this thinking or not. I'm sure in 6 months you can find a post about how I switched back to Vim. But for now, I'm really enjoying this experience.

Either way, thanks, signing off for now.

:wq

Remembering that I once was a terrible programmer

Chris Power — Thu, 03 Oct 2019 13:46:44 +0000

I think it's pretty fair to say that as we grow older and wiser, we tend to forget where we came from. And I think this recency-bias shows up frequently in software engineering as well. In software engineering, you tend to build on layers of layers of skills that you accumulate over a long period of time. After being a programmer for, lets say 10 years, you may forget how much you struggled early in the process. As you learn more advanced techniques, you tend to forget how much you may have struggled with even the simplest of programming concepts. I even find myself losing patience with new engineers from time to time, wondering how they couldn't understand some basic techniques that I take for granted every day.

Checking our Hubris

I think this is a form of hubris -- excessive pride or self-confidence. As we grow more experienced in a given field, we gain more and more hubris. We tend to forget from where we started, and feel more confident in the skills we've acquired. Some of you may think "But Chris! I struggle with imposter syndrome all the time!", and I agree with you (I do as well). Software Engineering is a very humbling field where one cannot literally learn enough. However, if you had 10+ years of experience and I asked you to write out a simple "fizzbuzz" problem on a whiteboard, you'd scoff at it wouldn't you? (you know you would).

The point I'm trying to make is that some people are just starting out in their programming careers. And they may struggle with basic algorithms, fizzbuzz-type challenges, and -- as we'll see in a moment -- writing a simple controller in Ruby on Rails. I think its easy to forget where you came from, because I know I have.

if you had 10+ years of experience and I asked you to write out a simple "fizzbuzz" problem on a whiteboard, you'd scoff at it wouldn't you? (you know you would).

On to REAPP -- a little diddy from 10 years ago

Recently, I received a security vulnerability alert for one of my private repositories in github. I recognized the name of the project, but I don't remember the last time I opened the codebase. The vulnerability alert came from a repository called "REAPP" (it stood for real estate application).

This application was my first attempt to build a Property Management platform -- a SaaS product that allows landlords/property managers to accept rent, manage tenants, and more. I have since re-written this application many times over the last 10 years or so, but this was it's first iteration. Clicking around in the codebase, I remembered how hard I worked to get this code to do much of anything. Specifically, I can remember a "properties" controller I wrote, and the struggle I had with it. I am pretty sure this controller made me abandon the project, because it was just too hard of a problem to solve.

The controller that ended this project

Let me just paste the code below, for you all to enjoy. Continue below the fold for my analysis and thoughts.

 # GET /properties/1
  # GET /properties/1.xml
  def show
    @property = Property.find(params[:id])

    #Handing tenants
    @tenants = @property.tenants.all
    if @tenants.empty?
      flash.now[:success] = "Weclome to LivingRoom!\r\n
                             We noticed you don't have any tenants set up, please find the 'tenants' box on the right hand side of your screen
                             and be sure to add your first tenant before anything else.
                             Thanks!"
    end

    #handling incomes, and the income chart series data
    @incomes_all = @property.incomes.all
    @incomes_full = @property.incomes
    @incomes = @property.incomes.paginate(:page => params[:income_page], :per_page => 5)
    @incomes_sum = @incomes_all.sum(&:income_amount)
    @income_chart_monthly = incomes_chart_series_monthly(@incomes_full, 4.months.ago)

    #handinling expenses and the expenses chart series data
    @expenses_all = @property.expenses.all
    @expenses_full = @property.expenses
    @expenses = @property.expenses.paginate(:page => params[:expense_page], :per_page => 5)
    @expenses_sum = @expenses_all.sum(&:expense_value)
    @expense_chart_monthly = expenses_chart_series_monthly(@expenses_full, 4.months.ago)

    @net_series = net_series_monthly()


    #zillow chart stuff
    @zillow_chart_url = zillow_chart()
    @valuation = zillow_value()

  end

  def zillow_chart
    @rillow = Rillow.new("MY-ZILLOW-CREDS")
    @zillow_search = @rillow.get_search_results(@property.street_address, 
                              @property.city+","+ @property.state)
    @zillow_property_id = @zillow_search.find_attribute("zpid")
    @zillow_property_id = @zillow_property_id.join

    @z_chart = @rillow.get_chart(@zillow_property_id, "percent", :width => 200, :height => 130, :chart_duration => "5years")                  
    @result_url = @z_chart.find_attribute("url")

    return @result_url.join
  end

  def zillow_value
    @rillow = Rillow.new("MY-ZILLOW-CREDS")
    @zillow_search = @rillow.get_search_results(@property.street_address, 
                              @property.city+","+ @property.state)
    @zillow_search = @zillow_search.to_hash
    @value = @zillow_search.find_attribute("valuationRange")
    return @value
  end

  # GET /properties/1
  # GET /properties/1.xml
  def show_expenses
    @property = Property.find(params[:id])
    @tenants = @property.tenants.all
    @expenses_full = @property.expenses
    @expenses = @expenses_full.paginate(:page => params[:page], :per_page => 10)
    @expense_chart_monthly = expenses_chart_series_monthly(@expenses_full, 4.months.ago)
  end


  # GET /properties/1
  # GET /properties/1.xml
  def show_incomes
    @property = Property.find(params[:id])
    @tenants = @property.tenants.all
    @incomes_full = @property.incomes
    @incomes = @incomes_full.paginate(:page => params[:page], :per_page => 10)
    @income_chart_monthly = incomes_chart_series_monthly(@incomes_full, 4.months.ago)
  end

  # GET /properties/1
  # GET /properties/1.xml
  def show_tenants
    @property = Property.find(params[:id])

    respond_to do |format|
      format.html # show.html.erb
      format.xml  { render :xml => @property }
    end
  end

Let's talk about instance variables

I don't think I knew what the difference was between an instance variable and a regular variable. I definitely felt the need to make almost everything an instance variable, regardless of my understanding.

How many variables are needed for income?

I pasted the show action in this controller for a reason -- its god
awful. I'm not sure why I needed 5 different instance variables to represent incomes:

    @incomes_all = @property.incomes.all
    @incomes_full = @property.incomes
    @incomes = @property.incomes.paginate(:page => params[:income_page], :per_page => 5)
    @incomes_sum = @incomes_all.sum(&:income_amount)
    @income_chart_monthly = incomes_chart_series_monthly(@incomes_full, 4.months.ago)

I most likely just wanted to use the paginated incomes for a property, not all of the incomes. From there, I could have pulled the chart data, and had it update when a user changed the query param for page. That would have been nice.

What's a service object?

I like this part of the controller:

    @zillow_chart_url = zillow_chart()
    @valuation = zillow_value()

First of all, these names make no sense. Why would I make a method named
zillow_chart that returns a url? These, and other methods, should have been placed in their own service objects to encapsulate different behaviors and concerns.

Conclusion. We were all like this, once

This was a fun trip down memory lane. But I think some lessons can be learned here. Whenever I find myself frustrated reviewing a junior developer's code, I should remember that I once wrote an insane controller with 40+ instance variables, no separation of concerns, and -- oh yeah -- INLINE API CREDENTIALS. I am also pretty sure this was completely untested. Actually let me check ... yup, no tests whatsoever. 😊

Global Snackbars in React with Redux, and Material UI

Chris Power — Thu, 12 Sep 2019 16:36:40 +0000

I'm working on a side project in React with Redux and Material UI. I love how snackbars look, and I wanted to create an easy system for displaying them throughout my application. If you've ever worked in Rails, picture the way you display flash messages. I wanted something simple like that amazing Rails feature.

About Snackbars

From the Material Design Guidelines: "Snackbars provide brief messages about app processes at the bottom of the screen".

The ☝ ️guidelines also specify the way you're supposed to implement snackbars: "Snackbars inform users of a process that an app has performed or will perform. They appear temporarily, towards the bottom of the screen. They shouldn’t interrupt the user experience, and they don’t require user input to disappear". This is the perfect use case to show a user when they completed a successful action on your application!

Snackbars in Material UI

Material UI is a component framework for React based on Material IO guidelines. They have an excellent snackbar component that we can leverage to show snackbar notifications to our users.

The problem in my application

I wanted to use snackbars all over my application. There are many places where a user can take an action that results in a snackbar appearing. I didn't want to instantiate a new Snackbar component for every single component that requires one to be displayed. Here is a quick example of one snackbar in my app:

The Solution: Redux!

Thankfully I am using React, with Redux. And I love using Redux as often as possible to solve my state issues. There is a pattern that I love with redux that I like to call the "redux ui" pattern. Basically I use redux to store at least some of my UI state throughout the app. This makes global UI changes (think users specifying dark mode in their apps) easy to store and propagate throughout your app.

Lets start by creating our reducers, this will give us the shape of our state for displaying snackbars:

// reducers/uiReducer.js
const uiReducer = (state = {}, action) => {
  switch (action.type) {
    case "SNACKBAR_SUCCESS":
      return {
        ...state,
        successSnackbarOpen: true,
        successSnackbarMessage: action.message
      };
    case "SNACKBAR_CLEAR":
      return {
        ...state,
        successSnackbarOpen: false,
        errorSnackbarOpen: false,
        infoSnackbarOpen: false
      };
    default:
      return state;
  }
};

export default uiReducer;

☝️ Will give us some structure for displaying a "success" snackbar, along with clearing out all possible snackbars we may want to create (including error and info... just in case).

Lets make some action creators to run the reducers.

// actions/snackbarActions.js
export const showSuccessSnackbar = message => {
  return dispatch => {
    dispatch({ type: "SNACKBAR_SUCCESS", message });
  };
};

export const clearSnackbar = () => {
  return dispatch => {
    dispatch({ type: "SNACKBAR_CLEAR" });
  };
};

Create a snackbar that uses the clearSnackbar() function to clear itself

// components/SuccessSnackbar.js or whatever you wanna call it
import { useDispatch, useSelector } from "react-redux";
import Snackbar from "@material-ui/core/Snackbar";
import IconButton from "@material-ui/core/IconButton";
import { Icon } from "@material-ui/core";
import { clearSnackbar } from "../../store/actions/snackbarActions";

export default function SuccessSnackbar() {
  const dispatch = useDispatch();

  const { successSnackbarMessage, successSnackbarOpen } = useSelector(
    state => state.ui
  );

  function handleClose() {
    dispatch(clearSnackbar());
  }

  return (
    <Snackbar
      anchorOrigin={{
        vertical: "bottom",
        horizontal: "left"
      }}
      open={successSnackbarOpen}
      autoHideDuration={4000}
      onClose={handleClose}
      aria-describedby="client-snackbar"
      message={
        <span id="client-snackbar">
          <Icon>check_circle</Icon>
          {successSnackbarMessage}
        </span>
      }
      action={[
        <IconButton
          key="close"
          aria-label="close"
          color="inherit"
          onClick={handleClose}
        >
          <Icon>close</Icon>
        </IconButton>
      ]}
    />
  );
}

in ☝️ note that we are using the clearSnackbar() function when the snackbar calls handleClose. Note, handleClose is called after the timeout specified, so the snackbar will automatically call this function after a certain amount of time.

Add this new snackbar component to your App.js file. This allows you to display a snackbar ANYWHERE in your app using redux:

return (
  <div>
    <SuccessSnackbar />
    <Router>
      //App stuff goes in here
    </Router>
  </div>
);

Dispatch the showSuccessSnackbar() function with your message whenever you want to show a success snackbar.

dispatch(showSuccessSnackbar("Success!"));

Conclusion

Success! Now you can display a snackbar anywhere in your React app using Redux. You are such a smart developer, aren't you? 😄

I found this to be a fun and interesting pattern to use when you want to globally display snackbars, or alerts, or anything in your React application. It's straightforward enough for any developer to understand, and its extensible to add anything: alerts, snackbars, messages, etc...

Scraping Reddit's API in NodeJS with Snoowrap

Chris Power — Fri, 30 Aug 2019 16:26:14 +0000

I'm still working on my side-project where I'm gathering information around the web. I'm eventually going to use this information in a weekly aggregate newsletter for Real Estate Investing and Property Management. If you're curious, The Newsletter is Here. For this part of the project, I'm going to scrape some of Reddit's API to find interesting Real Estate and Landlord Posts.

The Tooling

There is only one package you need to successfully scrape the reddit API in NodeJS: snoowrap.

Snoowrap is a "fully featured javascript wrapper for the Reddit API" -- quote taken from the github repo's index page. Snoowrap is really great, and it allows you to query posts, comments, scores, etc...

All of the responses are wrapped in their own little objects as well, and its all fairly well documented. Also, if you're using an IDE like Webstorm, you can easily auto-complete the functions and classes because of really great type definitions in the project.

Installing snoowrap

Install Snoowrap just like any other npm package in NodeJS:

npm install snoowrap --save

and require it:

var snoowrap = require('snoowrap');

Setting up Snoowrap

Before making any calls to the Reddit API, you have to go through an initial setup for oauth2 to generate an app, and tokens. This is fairly straightforward, but requires a few steps.

go to https://not-an-aardvark.github.io/reddit-oauth-helper/ and note the redirect URL you must use when creating your reddit app (the thing you use to call the API). As of this writing, the URL is: https://not-an-aardvark.github.io/reddit-oauth-helper/
go to https://www.reddit.com/prefs/apps/ and create a new app. It should generally look like this:

Note the redirect URI

Next, go back to https://not-an-aardvark.github.io/reddit-oauth-helper/, select the permissions you want, and generate your tokens.
Now, you can configure the snoowrap object in your script.

  const r = new snoowrap({
    userAgent: 'A random string.',
    clientId: 'Client ID from oauth setup',
    clientSecret: 'Client Secret from oauth setup',
    refreshToken: 'Token from the oauth setup'
  });

The Script for querying RealEstate subreddit

Now that you're all set up with snoowrap (great job, you smart developer you). You can query reddit's API in NodeJS with a script similar to the one below:

import snoowrap from 'snoowrap';

export async function scrapeSubreddit() {
  const r = new snoowrap({
    userAgent: 'A random string.',
    clientId: 'Client ID from oauth setup',
    clientSecret: 'Client Secret from oauth setup',
    refreshToken: 'Token from the oauth setup'
  });

  const subreddit = await r.getSubreddit('realEstate');
  const topPosts = await subreddit.getTop({time: 'week', limit: 3});

  let data = [];

  topPosts.forEach((post) => {
    data.push({
      link: post.url,
      text: post.title,
      score: post.score
    })
  });

  console.log(data);
};

Conclusion

The ☝️ script above outputs the top 3 posts from Reddit's RealEstate API. Pretty neat right? I thought this was a fun experience, and I really love how Snoowrap works. Now I can use this data to flesh out the newsletter I'm making, again, if your curious, you can check it out here.

Thank you, have a nice day!

Scraping websites with NodeJS

Chris Power — Wed, 21 Aug 2019 16:29:41 +0000

I'm currently working on a side project where I want to scrape and store the blog posts on certain pages. For this project I chose to use NodeJS. I have been working more with javascript lately so I figured this would be a fun thing to do with Node instead of Ruby, Python, whatever.

The tooling

There are two really great tools to use when scraping websites with NodeJs: Axios and Cheerio

Using these two tools together, we can grab the HTML of a web page, load it into Cheerio (more on this later), and query the elements for the information we need.

Axios

Axios is a promise based HTTP client for both the browser, and for NodeJS. This is a well known package that is used in tons and tons of projects. Most of the React and Ember projects I work on use Axios to make API calls.

We can use axios to get the HTML of a website:

  import axios from 'axios';

  await axios.get('https://www.realtor.com/news/real-estate-news/');

☝️ will give us the HTML of the URL we request.

Cheerio

Cheerio is the most amazing package I never heard of until now. Essentially, Cheerio gives you jQuery-like queries on the DOM structure of the HTML you load! Its amazing and allows you to do things like this:

  const cheerio = require('cheerio')
  const $ = cheerio.load('<h2 class="title">Hello world</h2>')

  const titleText = $('h2.title').text();

If you're at all familiar with JS development, this should feel very familiar to you.

The final Script

With Axios and Cheerio, making our NodeJS scraper is dead simple. We call a URL with axios, and load the output HTML into cheerio. Once our HTML is loaded into cheerio, we can query the DOM for whatever information we want!

import axios from 'axios';
import cheerio from 'cheerio';

export async function scrapeRealtor() {
  const html = await axios.get('https://www.realtor.com/news/real-estate-news/');
  const $ = await cheerio.load(html.data);
  let data = [];

  $('.site-main article').each((i, elem) => {
    if (i <= 3) {
      data.push({
        image: $(elem).find('img.wp-post-image').attr('src'),
        title: $(elem).find('h2.entry-title').text(),
        excerpt: $(elem).find('p.hide_xxs').text().trim(),
        link: $(elem).find('h2.entry-title a').attr('href')
      })
    }
  });

  console.log(data);
}

The output

We now have our scrapped information!

[ { image:
     'https://rdcnewsadvice.wpengine.com/wp-content/uploads/2019/08/iStock-172488314-832x468.jpg',
    title:
     'One-Third of Mortgage Borrowers Are Missing This Opportunity to Save $2,000',
    excerpt:
     'Consumer advocates have an important recommendation for first-time buyers to take advantage of an opportunity to save on housing costs.',
    link:
     'https://www.realtor.com/news/real-estate-news/one-third-of-mortgage-borrowers-are-missing-this-opportunity-to-save-2000/' },
  { image:
     'https://rdcnewsadvice.wpengine.com/wp-content/uploads/2019/08/iStock-165493611-832x468.jpg',
    title:
     'Trump Administration Reducing the Size of Loans People Can Get Through FHA Cash-Out Refinancing',
    excerpt:
     'Cash-out refinances have grown in popularity in recent years in tandem with ballooning home values across much of the country.',
    link:
     'https://www.realtor.com/news/real-estate-news/trump-administration-reducing-the-size-of-loans-people-can-get-through-fha-cash-out-refinancing/' },
  { image:
     'https://rdcnewsadvice.wpengine.com/wp-content/uploads/2019/08/GettyImages-450777069-832x468.jpg',
    title: 'Mortgage Rates Steady as Fed Weighs Further Cuts',
    excerpt:
     'Mortgage rates stayed steady a day after the Federal Reserve made its first interest-rate reduction in a decade, and as it considers more.',
    link:
     'https://www.realtor.com/news/real-estate-news/mortgage-rates-steady-as-fed-weighs-further-cuts/' },
  { image:
     'https://rdcnewsadvice.wpengine.com/wp-content/uploads/2019/07/GettyImages-474822391-832x468.jpg',
    title: 'Mortgage Rates Were Falling Before Fed Signaled Rate Cut',
    excerpt:
     'The Federal Reserve is prepared to cut interest rates this week for the first time since 2008, but the biggest source of debt for U.S. consumers—mortgages—has been getting cheaper since late last year.',
    link:
     'https://www.realtor.com/news/real-estate-news/mortgage-rates-were-falling-before-fed-signaled-rate-cut/' } ]

Please don't forget your history (in Git)

Chris Power — Wed, 07 Aug 2019 15:45:13 +0000

When you work on a new feature, or bug fix, and your code is approved; what do you do before merging it into master? Do you squash all commits, write the most beautiful commit message, and merge everything in? Or do you leave the history -- warts and all -- in place when merging?

I would hope you do the latter -- leaving every grisly commit for the world to see your process. A lot of people don't necessarily agree with this viewpoint; saying you must squash all commits, re-write your history to nice small chunks, and only merge the most beautiful git commits possible. I think that is kind of dumb for a few reasons:

You should never be breaking your build, so why re-write history?
When someone looks at a commit you made, they need granular detail
Managing groomed commits is a horrible experience.

Lets talk about these points in more detail.

1. You should never be breaking your build

There was a talk I remember seeing a while ago about ID software and how they developed games so quickly in their heyday. One of the points that stood out to me the best was "Never break the build". Whenever ID commits code for other engineers to test, the build always works, and the game is always playable. This kept the development team focused on only creating working features. They never made a whole bunch of WIP (Work In Progress) commits and told themselves they could fix it later; no, the build must always pass and the game must always be playable.

I took this to heart within my own engineering practices. Whenever I commit something to a code-base, I make sure it always works, the tests pass, and the "build" never breaks. This is the easiest way to stay focused, keep commits light, and keep your features solid. When writing code this way, you should never feel the need to squash commits, re-write commit messages, or any of that crap. Just write solid commits that don't break the current build, and you're well on your way.

2. People need granular detail when looking at commit history

Stop me if you've experienced this scenario: You're debugging some very intricate piece of code, and its a very dense and hard-to-understand authentication logic. You check the commit history to get some context and it says something like:

Create shopping cart feature for users to store items before checking out

WHAT?

Instead of seeing a commit with some context around this small piece of code, you are hit with a squashed commit message that summarizes a whole👏entire👏 feature👏. I see this happen way too often at many organizations. There is too much emphasis on squashing your commits to keep the history neat, but I think that is dumb. Instead, imagine seeing this series of messages

Created new auth function to store information for shopping cart feature

Fixed small bug with auth function

Now we have some context! You can see the actual thought process behind each change in this function you're debugging, and now you have more information to move forward with. You can see that your colleague created a function in the auth module (or whatever) related to this big feature, then later you can see they already tried to fix one bug! Perhaps that created the bug you're currently debugging? It just adds so much to your thought process and you guess much less.

3. Managing groomed commits is not fun

If your company or organization heavily practices re-writing history, you may have run into merge conflicts with your re-written commits. Lets walk through a scenario:

you add a new feature and make a commit
you add a test for the feature, and make a second commit
someone reviews your code and finds a small issues with the feature
you create a new commit to fix the bug, interactively rebase against master, and fixup commit #1 with this new work.
you realize you forgot something, rebase and fixup commit #2 with more tests
you rebase against master to get up to date and BOOM you hit a merge conflict.

It turns out that when you fixed up your commits and replayed the rewritten history of your branch, you have merge conflicts. This is a common problem I've seen many times. It's really hard to manager larger features and/or branches when you're continually fixing up commits with more work. Eventually you'll hit a merge conflict, and typically will create a whole new branch just to make everything better again.

Conclusion: Don't forget your history

I think in general, it should be best practice to leave your commit history in place when writing code. This will leave your colleagues with better documented commit messages, more context when dealing with bugs, and overall will be easier to work with.

Now if you'll excuse me, I have to commit this post without squashing any history!

Creating a SaaS product quickly with Rails an React

Chris Power — Tue, 30 Jul 2019 13:09:47 +0000

LivingRoom up and running!

The "Client"

Living Room Is a company (started by Browntree Labs) that creates software for property managers. LivingRoom wanted to build a beautiful application that empowers both tenants and property managers with tools to make managing apartments easier.

The Problem

I started LivingRoom myself, as both a personal project and a professional endeavor. I love making products, and I love working on things that interest me. In a very limited amount of time, I wanted to build a product that allowed landlords to:

collect rent
handle issues reported by tenants
manage leases
manage their properties, apartments, and tenants

and allows tenants to:

pay rent online
chat with landlords/property managers
allow

The Solution

Since we wanted to build a fully featured product within a very limited time-frame, we chose a set of very well known frameworks and libraries:

Ruby on Rails for rendering and API
React for more user intensive sections
Stripe for payment processing

Ruby on Rails for rendering and basic pages

Ruby on Rails is one of the most recognizable frameworks for building web applications. At Browntree Labs, most of our projects involve Ruby on Rails, so we're extremely familiar with the framework inside and out. Because the framework is so popular, every typical problem already has a really well thought out solution in the open source community.

A great example of a typical problem with a solution is a gem called Devise. Devise is a Ruby on Rails gem that adds authentication, and authorization logic to your application. By using Devise, we literally had authentication up and running within minutes. If we used a different framework that didn't have this problem solved by the community, it would have taken hours to handle all the nuances of authentication, not to mention the requirements of authorization (only allowing certain users to access certain information).

By utilizing Ruby on Rails, we were able to quickly iterate on large sections of this site. For example, pages like the Property Information page took no time at all to make, because there were no API calls, and no complicated set up. It was just a matter of fetching data from the database, and displaying information in HTML and ERB.

The property information page

Using React for more user intensive sections

Although Rails is great for displaying basic data, and creating basic CRUD (Create Read Update Destroy) interfaces, sometimes you need something with a more rich user experience. For example, when displaying a sortable table, with fuzzy searching capabilities, you don't want to refresh the page whenever someone types in a letter, or sorts a column. For these sections of the site, we used a Javascript library called React.

React, originally and currently being developed by Facebook, has been the most popular javascript library and/or framework for years now. Bursting onto the scene in 2013, React quickly gained popularity due to its simple API, its easy to understand patterns, and its powerful approach to adopting reactive programming to javascript applications.

By utilizing react, we were able to quickly create some amazing looking things in our application. Our data tables throughout the application; for example, were a feature we used react for.

The Units data table

We used React to render the above table in some HTML generated by Rails. When a user tries to search for a unit, React will make a call to rails to fetch any possible matches for that unit name. With this setup, a user has a really snappy interface to sort and search for information. There are plenty of other examples throughout the app where we used React. Such as: Unit-wide chat between tenant/landlord, Issue creation and management, Tenant and property data tables, and property-wide chat between tenants and landlords! Since this was all done with well known tools, we were able to create everything very quickly and painlessly.

Using Stripe for payment processing

The world of online payment processing is a bit complicated. There are many solutions to many different problems. But for us, we chose Stripe. Stripe has some of the best API documentation around, and its the easiest payment processing technology to work with, because it has packages for any possible language/framework you can think of. By using Stripe, we had an almost plug-and-play solution for processing user payments immediately.

Our setup for payments was a little odd. We needed to use the Stripe Connect platform to enable us to allow third parties to charge their customers (landlords charging tenants), and get paid through our application. There was some custom code involved in setting this up; however, the documentation was excellent, and in generally this was accomplished fairly easily.

Conclusion

From start to finish, we only spent a couple of months on LivingRoom in our part time. But because we stuck to well-known tools, we accomplished a lot within a very limited time-frame. Using well-known tools and patterns are part of what we do at Browntree Labs, and this project was just another example of how well this strategy works.

Re-writing DRAFTs Ember app in React

Chris Power — Wed, 26 Jun 2019 20:43:39 +0000

Using React best practices and tools, I helped re-write DRAFT's web application within 9 months. Here is the overview of how that was accomplished.

The Client

DRAFT is a daily fantasy sports company that prides themselves
on unique and fun DFS sports games and formats. They have multiple betting games for sports ranging from Football to Golf. In 2017 they were acquired
by Paddy Power Betfair, and have been operating as DRAFT (by Fanduel) since 2018. DRAFT mostly focuses on their iOS and Android mobile apps, but they also have a very extensive Web Application that compliments the mobile apps, originally built in Ember.

The problem

In early 2018 due to the lack of interest in the engineering team, and a lack of available talent, and a new investment from PPB, DRAFT began the process of re-writing their Ember app in React. DRAFT has a robust Ruby on Rails API that serves the mobile applications,
and the web application; however, adoption of new API calls was dwindling due to the lack of Ember work the team was putting out. The
front-end client (the Ember web application) was missing out on new functionality and new game formats.

The solution

Browntree Labs was originally hired to work on the Ruby on Rails API in anticipation of the upcoming football season. After 3 months on the API team;
however, it became clear that the new React team needed help pushing the re-write project over the finish line. In a very short amount of time,
yours truly was working on a very large and complicated React application, implementing features as quickly as possible. the team and I used a few main
concepts to build features quickly and maintain great code:

React
Atomic Directory Structure
Redux for State Management

React

React is an amazing javascript component library written by facebook. React makes it very easy to write
reusable components for your project.

DRAFT has a lot of re-use in their web application. Imagine the concept of a
'player card'. A 'Player' could be a professional athlete who plays in the NHL,
the NBA, the MLB, or the PGA. In the re-write, we created the concept of a
'player card' that encapsulates all of these scenarios, and we were able to
share it throughout the whole application. By creating solid components in React
and re-using them in different places, we quickly implemented many features of
the previous web application.

Atomic Structure

For this project, the team and I used the Atomic Design
Pattern
to structure the application. If you're unfamiliar with this pattern, it looks
something like this:

atoms - molecules - organisms - templates -> pages

The Atomic Structure pattern works very well when applied to a React Project. In
React, you create everything in terms of components. And with an Atomic
Structure, you can think of differently sized components fitting neatly into the
various parts of the structure.

The player card -- an organism

Imagine our Player Card from above. There are actually many parts to this
component. We have some components that span multiple levels of our Atomic
Structure in our Player Card alone! We have a player avatar, that stems from an
avatar atom component. We have a table for stats, that comes from a
statList molecule component. And we put everything together in the
playerCard which happens to be an organism component -- a component that
combines molecules and atoms to form a more complex piece of UI.

the player list -- a template

The playerCard component may be grouped up into a list of players. This list
could be considered a template. And you can combine these templates together
to form a page. In our image above, we can see the Page that displays the
winnings and scores from past contests in DRAFT.

the results page -- a page

Using a set structure helped us come up with UI components very quickly, as we
had a good mental picture of how things should fit together through code. We
also were able to quickly re-use large pieces of functionality, because we split
up our code in neatly packaged components, like organisms and templates.

Redux for State Management

Redux is an amazing tool for managing state throughout a Javascript application. Taken from the Redux
website:

Redux is a predictable state container for JavaScript apps. It helps you write
applications that behave consistently, run in different environments (client, server, and native), and
are easy to test. On top of that, it provides a great developer experience, such as live code editing combined with a time traveling debugger

Redux works really nicely with React with the React-Redux package.

Within the DRAFT application, we wanted to maintain the concept of a page needing a specific set of data. This differs from
some other javascript frameworks that use the MVC model -- which says a model holds data. We used reducers -- a core concept of redux --
to slice our data into relevant chunks to use in a given page on the application. Using data this way allowed us to easily manage
a complex set of data through solid reducer design and re-use.

A quick example would be the Results page shown above. When we make a request from the API, we get a whole bunch of data. Most of this
data is not necessary for the Results page; however, we can use Redux's reducers to slice the data to only the relevant
pieces we need. Slicing the data is a great way to keep each page lean.

In Conclusion

React is an amazing library, and when you couple it with the right tools and concepts, you can very quickly create very complicated
applications. We (the front-end team at DRAFT and I) used a few principles and concepts to very quickly re-create a whole
complex web application in React with a very tight deadline.

What making a game in Vue.js taught me about Front-end development

Chris Power — Tue, 04 Jun 2019 00:00:00 +0000

This is the most useful thing I have ever done in my career. I have created my
masterpiece, my magnus opus. Beethoven himself would be shaking in his little
boots at the awe of this creation. Dear reader, I've done it, I have created:
"Battleshit".

https://codepen.io/cpow/pen/JqVjRL

A disclaimer

I want to make it perfectly clear that I know the code here is terrible. It was
hastily written, it probably has bugs, and it doesn't follow vue.js conventions
all that well, at least, to my understanding.

So why write it?

I wanted to learn just a little bit about Vue.js and to prove a little theory
I've had for some time now. That theory goes like this: All javascript
component frameworks operate in mostly the same way. They all have similar
patterns, conventions, and best practices. And they're all very easy to pick up
and start programming with. Our over-engineering of tools, tooling, and the lack
of a large standard lib in Javascript is what makes front-end programming hard.
Having to learn Vue.js, or React, or Ember, or Angular is easy; having to learn
the respective ECOSYSTEM of these frameworks is difficult. In Front-end development,
all the concepts are the same, we just find more and more clever ways to make them
difficult to understand.

In Front-end development, all the concepts are the same, we just find more and more clever ways to make them difficult to
understand.

So, onto BattleShit

This is a really really silly game I made in about an hour, give or take. I just
wanted to learn Vue.js a little bit, and through that, understand our ever evolving
front-end ecosystem just a little bit more. I can safely say that after
Battleshit, I have a greater understanding that we are just re-inventing the wheel
over and over again.

Anyway, enjoy Battleshit!