We're Happier Together! NYC Devshop has joined the HappyFunCorp family! Learn more!


Devshop Blog

7 results returned for "Programming"

Tuesday, Nov 1st, 2016

Lauren Basil

8 Technology Trends to Look for in 2017

1. Artificial Intelligence

Artificial intelligence and advanced machine learning are composed of technologies and processes like deep learning and neural networks. Techniques are moving beyond rule-based algorithms to create systems that understand, learn, predict, adapt and potentially operate autonomously making smart machines appear "intelligent". As encouraging as AI and machine learning sounds, many people don't realize that as AI evolves, so does its criminal potential.

2. Intelligent Apps

Intelligent applications such as virtual personal assistants (VPAs) are making everyday tasks easier. VPNs and virtual customer assistants (which promise to enhance customer service and sales) should transform the nature of work and structure of the workplace.

3. Intelligent Things

Intelligent things, such as drones, autonomous vehicles and smart appliances, permeate the environment, but we expect to see a shift from stand-alone intelligent things to a collaborative intelligent things model. Intelligent things will leverage AI and ML to interact with humans and surroundings.Smartphones, smartwatches and smartglasses will partner with intelligent things and form a Smart Ecosystem.

4. Virtual and Augmented Reality

Immersive technologies, such as virtual reality (VR) and augmented reality (AR), have captured the imagination of gamers and other consumers, but they will increasingly have business-to-business implications. We are still in the beginning stages of VR and AR and we will evolve dramatically through 2021. We will see rooms and spaces become active with things, and their connection through the mesh will appear and work in conjunction with immersive virtual worlds.

5. Digital Twin

Within three to five years, hundreds of millions of things will be represented by digital twins. A digital twin is a dynamic software model of a physical thing or system that relies on sensor data to understand its state, respond to changes, improve operations and add value. Organizations will use digital twins to proactively repair and plan for equipment service, to plan manufacturing processes, to operate factories, to predict equipment failure or increase operational efficiency, and to perform enhanced product development.

6. Blockchain Technology

Current blockchain technology hype is around the financial services industry, but a growing number of industries have joined the party. According to the Economist, a blockchain is a distributed database that maintains a continuously-growing list of records called blocks secured from tampering and revision. Each block is chained to the previous block, and the process is noted in a specially encrypted peer-to-peer network.

7. Conversational Systems

Currently the focus for conversational interfaces is focused on chatbots and microphone-enabled devices. Soon, they will move from chatbots to a broader digital mesh, which will move to an expanded range of endpoints that we will all interact with on a daily basis. These will work together to a growing extent. This will enhance ambient digital experience in the process.

8. Digital Technology Platforms

Digital technology platforms provide the basic building blocks for a digital business. There are five major focal points to enable digital capabilities and business models:

  • Information systems

  • Customer experience

  • Analytics and intelligence

  • IoT

  • Business ecosystems

Every organization will have some mix from across these five digital technology platforms. The platforms provide the basic building blocks for a digital business and are a critical enabler to become a digital business.

Wednesday, Jul 20th, 2016

Lizzie Healy

Benefits To Building A MVP

Are you jumping in head first or biting off more than you can chew? At Devshop, we work with all levels of business, from startup to enterprise level, and everything in between. Sometimes we are tasked with building an application for an existing business, but often the application is the business. In these cases, where the platform is so heavily intertwined with the business itself, the importance of a successful, streamlined application with the cleanest functionality out of the gate becomes even more relevant.
When we are approached by businesses in the idea formulation phase of development, we find that many platforms stand to benefit from building a MVP up front. We often recommend the MVP, or minimum viable product, route because it helps in determining the practicality of an idea is at its core. Creating an initial MVP does not mean releasing an unfinished product. Your MVP should still accomplish your main goals, but save the bells and whistles for V2. Coming from a non-tech background, one of the first things I learned working at a development shop was that a website or application is never really done. It's constantly evolving, developing, and pivoting based on the needs of the user and the goals of the business. Focusing on the main functions of your application as a starting point comes with a long list of benefits.

  1. Getting To Market Sooner

    Competition is constantly present, so a business stands to benefit from any advantages possible. Being the first to market provides a leg up on the competition, gaining valuable recognition before similar apps are on the scene.

  2. Avoiding Overwhelming Users
    A major hurdle in acquiring or converting users lies in their ability to grasp the concept of an app. Beyond designing UX with the user in mind, building an initial product that is simple enough for a user to easily understand can aid in overcoming this barrier.

  3. Getting Real User Feedback Before Adding Features
    User feedback gets watered down when too many features are introduced, making it harder to draw conclusions about the core functionality of the application. Streamlining what components users are interacting with allows them to provide deeper insight into the overall concept, rather than being bogged down insignificant details.

  4. Avoids Wasted Time And Resources
    A client who approaches us with an extensive list of features for their initial product will often be met with a longer timeline and a higher estimate to build it. Whether you're a startup or an enterprise level client, no one benefits by wasting time and money. Creating an initial MVP accomplishes the ultimate goal while saving man hours and cutting down on costs.

  5. No Product Is Ever Finished
    We know you don't want to release an unfinished product to market, and neither do we. We would never recommend that. What we would advise is that no product is ever really complete, so if you are waiting until your application is finished you will never launch. Leaving room to grow once your application is in the hands of users ensures that you're are growing in the right direction.

  6. Lessens Chances For Bugs
    Have you ever opened an application that unexpectedly quit on you in the middle of an action? Frustrating. We want to avoid that. Throwing everything but the kitchen sink in means less time devoted to core functions and a greater likelihood of having bugs within the application.

  7. Makes Implementing Changes As Simply As Possible
    Venmo didn't start out seeking to be Venmo, and Uber offered a fraction of the benefits it does today. Features can always be added on, but changes can occur more quickly when you begin with a less complex product. You may be one easy pivot away from the next best thing, but going too far down a specific path with your initial product can deter any simple adjustments.

Building an MVP allows for easier analysis and adjustments, which will ultimately result in the best possible product. A MVP is a way to test a platforms business model with the least amount of complex features. While this is not a one size fits all method, considering creating an MVP initially has clear benefits that could ultimately mean the success of an application in the long run.

Thursday, Jun 2nd, 2016

Mike Trumpf

A Lesson In APIs

Disclaimer - This article is meant to provide a high level perspective of what an API is, and what it can do for your app. If you are a developer with API experience, this blog post probably isn't for you. If you are new to programming, an entrepreneur developing app ideas for the first time, or a non-tech person dealing with developers, this will serve as a handy cheat sheet reviewing the basics of APIs.

What Are APIs?
API stands for Application Programming Interface. An API is a set of requests and responses that you can ask and receive from another program. Applications create APIs that allow others to access their information or use their services. When you see the option to "Login with Facebook" on an app, this would be an example of an app using Facebook's API. When you receive a message alerting you that your Uber is on it's way to you, the messaging API Twilio is at work. Though you may not have realized it, you deal with APIs on a daily basis.

Why Use Them?
APIs can be a great way to "quickly" add new features to your app and gather information about your users. Having this information can also lead to a more personalized experience for them as well. When a user signs up for your app using their Facebook login, you can instantly gather a wide range of information on them, such as their name, age, location, gender, hobbies, friend list, etc. You can then use that information to perform a variety of actions in your app, such as filling in their user profile, tailoring custom content to them, connecting them with their friends already on the app, and much more. However, not all APIs fall under content gathering. Others, such as the aforementioned Twilio messaging API, can add tools to your application's workbelt. Actions like sending a text to a user that their cab is on its way, or texting a password reset code, would be a lot harder if it wasn't for the Twilio API. These service APIs open up a realm of new ideas and possibilities. Many times the "Ah ha!" moment for a new app idea comes from the release of a new API!

Are APIs Free?
There are many free-to-use APIs. In return they ask that somewhere within your app, you state that you are using them. They want that advertising! Other APIs are not free, but come with a free trial period. The purpose of this free trial period is for you to make sure that this API fits into your app the way you hoped it would. When the trial period concludes, you are generally presented with a subscription based plan.

All APIs are not created equally...
You may have noticed that when describing why to use an API, I have the word "quickly" in quotes. This is because not all APIs and their documentation are built equally. There isn't a standardized template for how to build an API, so it is completely up to each service how they allow users to make requests and receive information. It also may not be a priority for them to have extensive documentation on how to use their API. Integrating an API that has great documentation as well as a support staff at your disposal can be an amazing experience, as was mine with the Eligible API. On the other end of the spectrum, an API with terrible documentation can lead to hours searching for answers on stack overflow, and other features of the app having to be pushed back.

Places to find APIs
Interested in what kind of APIs are out there? There are services that can help you discover what is out there such as Programmable Web and Mashape. Sometimes the best thing to do is just a good old-fashioned Google Search. Who knows, there may be an API out there you've never heard of that makes one of your latent app ideas possible now!

APIs are a great way to add features to your application and make a more personalized experience for your users. Hopefully, with this knowledge you can see the power of APIs, as well as some of the challenges they can bring developers. It can be tempting to want a bunch of APIs integrated with an application. Who doesn't want more information about their users and more tools in their app? Just know that trying to integrate an API with weak documentation can have you spending hours on something that might be nice to have, when those hours can instead be used on perfecting what you already do have.

Monday, Jul 7th, 2014

Jared Rader

Dynamic Styles Made Easy in Rails

While I definitely consider myself more of a backend developer, I've been lucky that my job pushes me to get more comfortable with front-end implementation. I learned a pretty neat and simple trick the other day for dynamic data visualization that I felt was worth sharing.

Our latest project, Daily Poll, sends users - you guessed it - a daily poll via text message. The questions, for now, are yes/no questions, and we were tasked with displaying the results on the homepage as a colorful bar chart.

We need the heights of each chart to be representative of the percentage of votes. How could one get this to be dynamic?

One way to accomplish this is with inline styling. Inline styling is generally frowned upon, but it makes this really easy.


%h2 YES!
= image_tag("cheering_blue.png")
.yes-box{:style => "height: #{box_height(poll.yes_count,
%span= number_to_percentage(poll.yes_percent, precision: 0)
%h2 NO!
= image_tag("cheering_red.png")
.no-box{:style => "height: #{box_height(poll.no_count,
%span= number_to_percentage(poll.no_percent, precision: 0)

You'll notice inside the inline styling for the yes and no boxes, we call a helper method box_height, which handles generating the heights we need. We pass poll.yes_count or poll.no_count (methods we've defined in the Poll model) along with the total number of votes.

In box_height, we need to determine what our maximum height can be. Once we have that, we can multiply that by the number of total yes/no votes, dividing the product by the total number of votes:

def box_height(yes_no_votes, total_votes)

if total_votes < 1
return 0
380 * yes_no_votes / total_votes

What's going on in this method? If no vote records exist for the poll, we just return 0, giving the chart a height of zero. Otherwise, we multiply 380 (the max height for our charts) by the number of yes or no records, divided by the total number of vote records. Thus, if we have 52 yes votes out of 100, we get a height of 197px, or 52% of our max height. Perfect!

Spice it up with jQuery
We wanted to implement a cool effect where the polls would sprout up from nothing to their appropriate heights as you scrolled to that section of the page. With jQuery, this isn't too difficult to accomplish.

I hadn't worked with any scrolling effects before, so I did a quick Google search and popped open the jQuery docs and a few StackOverflow posts on the subject. I came across a simple solution for determining whether an element is scrolled into view. I define this function above the $(document).ready() {} declaration:

function isScrolledIntoView(elem) {

var docViewTop = $(window).scrollTop();
var docViewBottom = docViewTop + $(window).height();
var elemTop = $(elem).offset().top;
var elemBottom = elemTop + $(elem).height();
return ((elemBottom <= docViewBottom));

Using jQuery's .offset() and .height() functions, I determine how far from the top is an element on the page, returning true or false if the bottom of the element is less than or equal to the height of the window plus how far it is from the top of the window. That may sound confusing - it took a few minutes for me to wrap my head around it - but after playing around in the Chrome console, I got it. So I'd encourage you to do the same until the first sentence of this paragraph makes sense.

Now that I have a function that tells me whether a certain element is in view, I can work some real jQuery magic. If the element is in view, I can use jQuery's .slideDown() method to make the bars sprout into view:

$(window).scroll(function() {

if (isScrolledIntoView($('.question-header'))) {
} else {

I suppose the .slideDown() method is called that because jQuery's creators decided that most elements would be sliding into view from top to bottom, but it still achieves the desired effect if you've got something going from bottom to top. It may seem a little counterintuitive at first, but it works!

Friday, Jun 20th, 2014

Shawn Broukhim

Ajax Post Requests in Rails

Completing asynchronous Javascript CRUD actions is easy with jQuery... Here's a 4 step guide to making posts without reloading the page (assuming your models/views/controllers are already set up).

1. Add a Javascript event listener to the form's submit action and prevent the form's default behavior (an HTTP post request) upon submission: (the following is a user sign up route implemented using Ajax, ".new_user" is the class of the form element.)

   $( document ).ready( function() {

$(".new_user").submit( function(e) {

2. Instead make a post request using jQuery & include your model's parameters as arguments to be passed to the controller:

    var $this = $(this);

var name = $this.find("#user_name").val();
var phone = $this.find("#user_phone").val();
$.post('/users', { user: { name: name, phone: phone } } )

3. In the controller layer, parse the incoming parameters and render the appropriate response as a json object (inside user_controller.rb):

   def create

@user = User.new(user_params)
if @user.save
render json: { status: 'success' }
render json: { status: 'failure' }

4. Handle the response by updating the views appropriately:

  .done(function(res) {

if(res.status == 'success') {
"<div id='subscribed'><div class='arrow-left'></div>
<span>Woo hoo! You're subscribed!</span>
} else {
"<span> Something went wrong </span>")

Using Ajax to handle CRUD actions is helpful in streamlining the functionality of an app. Having too many page reloads slows down the app and diminishes user experience. It is important to get comfortable using jQuery/Ajax as a strategy in the development process.

Thursday, Jun 19th, 2014

Jared Rader

My First App Deploy to Digital Ocean

I've developed a lot of respect for dev ops over the last couple days. In my beginning developer days, I was, of course, introduced to Heroku, as their platform makes it incredibly easy to deploy your app online. While Heroku is great, if you've got an application that sees a lot of traffic and requires a few worker dynos, you'll be surprised at how quickly the price jumps from free to less affordable.

At DevShop, we use Digital Ocean, a more developer-friendly and less expensive choice for deploying your web app.

Deploying to Digital Ocean is a little more involved than what I'm used to. While the process gets quicker the more you do it, there are about 40 unique steps involved.

I've been battling with an internal server error over the past couple days while trying to deploy my first app to Digital Ocean, and it turned out the bug was very simple fix that had to do with a new addition to Rails: the secrets.yml file.

In Rails 4.1, all apps come with a secrets.yml file, a convenient file for storing all your sensitive environment information, such as API keys, as well as the secret token Rails uses to protect session variables. In previous versions, this was handled by the secret_token.rb file in the initializers folder. In the new secrets.yml file, your production secret key is not automatically generated. I didn't understand why my app wasn't appearing on the production site until I viewed the Apache logs that led me to the discovery.

The moral of this story is - be aware of what version of Rails you're installing, and make sure you read up on all the changes made.

A little more on secrets.yml
For previous Rails apps, I used the figaro gem to store application secrets. With secrets.yml, it would at first seem that there's little need for the figaro gem. There are a few important things to consider when comparing the new Rails convention for storing secrets and figaro, which the creator of figaro, Steve Richert, outlines nicely here. One of the main drawbacks to secrets.yml that Steve outlines is that it doesn't use ENV, so secrets.yml needs to be installed on every application server. Figaro nicely merged the secrets set into the application's env vars, making it easy to use for deployment. Also, secrets.yml is not automatically added to your .gitignore file, which figaro handles for you.

This new Rails convention will likely continue to improve in future releases, so it's worth keeping an eye on.

Tuesday, Jun 17th, 2014

Tea Ho

Two ways to do a custom file field

File input fields are rendered differently in every browser and none of them are particularly attractive. This is especially annoying if you have a specific design you want implemented across browsers.

In attempting to customize the file field, I have found two ways to do this:

1. Pure CSS

   <input type="file" class="pretty-input">


    .pretty-input::-webkit-file-upload-button {

display: none;
.pretty-input::before {
content: 'Choose an image';
color: #fff;
width: 150px;
height: 45px;
line-height: 45px;
text-align: center;
text-transform: uppercase;
display: inline-block;
border-radius: 3px;
background: teal;
padding: 5px 8px;
outline: none;
-webkit-user-select: none;
cursor: pointer;

* For those who are jQuery shy, this is a quick fix.

* You are only affecting the original element, so it's more semantic.

* I still haven't figured out how to do this for Mozilla

* In its active state, you'll notice there is what appears to be extra padding on the righthand side. This is due to the actual input button still taking up space.

* If your button has a transparent background for some reason, or depending on the size of the button and its shape, you might still see the "no file chosen" text.

2. CSS & jQuery


   <button class="pretty-input"> Choose an image </button>

<input type="file">



display: none;
.pretty-input {
content: 'Choose an image';
color: #fff;
width: 150px;
height: 45px;
text-align: center;
text-transform: uppercase;
display: inline-block;
border-radius: 3px;
background: teal;
padding: 5px 8px;
outline: none;
cursor: pointer;
border: none;




* Note: this only works if the fake button is placed right before the real input. If you want it elsewhere, you can target a specific ID.

* It's easier to style a button from scratch without having to override the original input's settings (you don't have to deal with any of the annoying blue focus outlines or anything)

* You could potentially make anything an input field, including photos or whatever you want.

* It works in every browser

* You need to create an extra div so your DOM isn't as clean.

* It requires more code.