fbpx

We’re Hiring: iOS Product Developer

Trim Agency is seeking an iOS developer to join their startup studio. The ideal candidate will not only love to code, but love to see companies grow from zero to launch, and scale companies from one to n.

The Trim product mobile stack for iOS is Swift (or Objective C) / Rails API / Postgress on Heroku for native mobile. Our ideal candidate is has a working understanding of API development but has proficiency in Swift development for zero-to-version-one products. The candidate will fearlessly dissect 3rd party library and API documentation and implement RESTful, XML, and JSON based web services as needed.

Trim Agency is a startup studio, and practitioners of agile development. We seek engineers that can rapidly build high-quality applications, and can consult Product Owners through our process. We have solved enterprise problems through technology for billion dollar corporations, but our passion is building products for startups through an accelerated co-founder-as-a-service offering. For every project, we form micro teams of one designer, one engineer, and one strategist. Our portfolio companies have raised over $2.6 million in funding over the last 18 months, and we are preparing for the next cohort of companies to build, launch, and grow within our portfolio.

We expect our developer candidate to own a consultancy mindset, self-start on product features, and maintain sprint responsibility week-to-week by working closely with product owners and teammates. Our culture is fostered through instituting the importance of the 8 TLC’s (Exercise, Diet, Nature, Service, Relationships, Recreation, Relaxation / Stress Management, and Spiritual Health), and we structure our weekly sprints to include both “inspo days”, as well as paid investment time on Fridays. We are also the “Coolest Office in South Florida” (as named by South Florida Business Journal, 2015), creators of General Provision coworking, and home to Broward’s first coding bootcamp, Wyncode Academy. You can find us in FATvillage, Fort Lauderdale, but our clients are all over the country.

REQUIREMENTS

iOS Development experience with Swift (Objective C a plus). Working understanding of API Development (Ruby on Rails or Node.js experience is a plus) Agile Development experience Familiar with GIT for version control Value based testing, including test-driven development Fearless approach to innovation Great written and verbal communication You must consider code your craft.

BENEFITS

Paid Vacation Paid Investment Time Unlimited Remote Work In House Barista, Coffee Bar, Beer on Tap Free Massages and Catered Lunch Health Insurance

Upload Resume

Testing Modules in Rspec

There comes a time when we might need to write some unit tests for a module. To do this, we can just extend some class and test the methods on that class. Here is an example using Rspec’s subject class; extending it with SomeProject::MyHelpers to unit test a method called :helpfulness.

require 'spec_helper'

describe SomeProject::MyHelpers do

  # add the module methods as instance methods to Rspec's subject
  subject do
    self.extend(described_class)
  end

  describe 'The helpfulness of my helper' do
    it 'helps a lot' do
      expect(subject.helpfulness).to eq "a lot"
    end
  end
end

Rails Forms: Validating and Persisting Duplicate Parameter Names

Building Rails forms is a pretty straightforward process but, once in a while, I run into a ‘gotcha’ that needs a simple solution. This week I was building a form where, if the user selects a particular subset of radio buttons, a text field is shown and the user is required to enter a string.  The form data is persisted using an enum to capture the radio button selection and a string attribute to capture the text entry if any.   The ‘gotcha’ is that the text field input needs to be placed in multiple places within the form,  and rails will ignore duplicate parameter names.

To allow the submission of the same input field multiple times, I added an empty array to the input name:

 

   <input id = “user_text_entry”, name=“user[text_entry][ ]”, placeholder=“Enter text” >
         => [,,”user’s text entered”]

 

More on parameter naming conventions can be found here.

 

To implement front end validations, I used jQuery’s :visible selector to ignore the hidden text fields.

 

var userTextEntry = $(‘.text-required-radio-box’).find(‘*’).filter(‘:input#user_text_entry:visible');

Rename a Phoenix Application

When we build a Phoenix application with $ mix phoenix.new my_app, our application module name is set to MyApp. This module name, as well as the snake case version, is referenced everywhere, making it very cumbersome if you need to ever rename the application. Here is a shell script I wrote the does the job in less than a second. Just make the script executable and run it by passing a snake case version of the new name for your application. You will be shown a preview and asked to confirm before proceeding.

Common Table Expressions in Postgres

PostgresSQL WITH Queries, also known as Common Table Expressions (CTEs), allows us to write complex queries by defining temporary tables for use in a larger query. In other words, we can create in-memory temporary tables and query against them. Here is an (trivial) example where we want the email addresses of all the users who signed up on the biggest sales day.

WITH top_sales_by_date AS (
  SELECT date, SUM(order_total) AS total_sales
  FROM orders
  GROUP BY date
  ORDER BY total_sales DESC
)
SELECT email
FROM users
WHERE sign_up_date = (
  SELECT date
  FROM top_sales_by_date LIMIT 1
)

The top_sales_by_date is a table created just for this query that aggregates the order totals grouped by date, the ordered by total sales. We can use the date value from the top record in the temp table to find the emails of users who signed up on this date.