Feed powered byStream Blue Logo Copy 5
Ruby

Ruby

Application and Data / Languages & Frameworks / Languages

Decision about HTML5, Ruby, Babel, Webpack, Visual Studio Code, GraphQL, Graphcool Framework, Figma, TypeScript, JavaScript, Framework7, Css

Avatar of jdspugh
Software Engineer / Project Manager / Technical Architect
HTML5HTML5
RubyRuby
BabelBabel
WebpackWebpack
Visual Studio CodeVisual Studio Code
GraphQLGraphQL
Graphcool FrameworkGraphcool Framework
FigmaFigma
TypeScriptTypeScript
JavaScriptJavaScript
Framework7Framework7
#Css

I needed to choose a full stack of tools for cross platform mobile application design & development. After much research, trying different tools, and 18 years of mobile design & development, these are what I came up with that work for me today:

For the client coding I chose Framework7 because of its performance, easy learning curve and very well designed, beautiful UI widgets. I think it's perfect for solo development or small teams. I didn't like React Native. It felt heavy to me and rigid. Framework7 allows the use of #CSS, which I think is the best technology to come out of the #WWW movement. No other tech has been able to allow designers and developers to develop such flexible, high performance, customisable user interface elements that are highly responsive and hardware accelerated before. React Native contains a very limited interpretation of #CSS which I found very frustrating after using #CSS for some years already and knowing its powerful features. The other very nice feature of Framework7 is that you can even build for the browser if you want your app to be available for desktop web browsers. This is not possible with React Native yet.

JavaScript is very far from an ideal language, to say the least. To make life bearable I managed to configure TypeScript to work with the latest version of Framework7. This makes me feel like I'm back in the good old Java days. I consider TypeScript to be one of the rare best creations to come out of Microsoft in some time. They must have an amazing team working on it. It's very powerful and flexible.

For the user interface design and prototyping I use Figma. Figma has an almost identical user interface to Sketch but has the added advantage of being cross platform (MacOS and Windows). Its real-time collaboration features are outstanding and I use them a often as I work mostly on remote projects. Clients can collaborate in real-time and see changes I make as I make them. The clickable prototyping features in Figma are also very well designed and mean I can send clickable prototypes to clients to try user interface updates as they are made and get immediate feedback.

For the UI icons I use Font Awesome Pro. They have the largest selection and best looking icons you can find on the internet.

For the backend I chose Graphcool Framework. It has great customer support and a very accessible free startup plan for working on new projects. I was never a fan of relational databases so I'm very pleased to see NoSQL / GraphQL databases coming to the fore and I'm happy to use them. No more server side API development required! NoSQL databases are so much more flexible and the way I think databases were meant to be from the start.

For the IDE I use Visual Studio Code which is blazingly fast and silky smooth for editing code with the ultimate TypeScript checking (since both products are written by Microsoft).

I use Webpack and Babel to compile the JavaScript. TypeScript can compile to JavaScript directly but Babel offers a few more options and polyfills so you can use the latest JavaScript features today and compile to be backwards compatible with virtually any browser.

I use some Ruby scripts to process images with ImageMagick and pngquant to optimise for size and even auto insert responsive image code into the HTML5. Ruby is the ultimate cross platform scripting language. Even as your scripts become large, Ruby allows you to refactor your code easily and make it Object Oriented if necessary. I find it the quickest and easiest way to maintain certain aspects of my build process.

What tools do you use? Have you tried these ones?

15 upvotes7 comments15.4K views

Decision at SmartZip about Amazon DynamoDB, Ruby, Node.js, AWS Lambda, New Relic, Amazon Elasticsearch Service, Elasticsearch, Superset, Amazon Quicksight, Amazon Redshift, Zapier, Segment, Amazon CloudFront, Memcached, Amazon ElastiCache, Amazon RDS for Aurora, MySQL, Amazon RDS, Amazon S3, Docker, Capistrano, AWS Elastic Beanstalk, Rails API, Rails, Algolia

Avatar of juliendefrance
Principal Software Engineer at Stessa
Amazon DynamoDBAmazon DynamoDB
RubyRuby
Node.jsNode.js
AWS LambdaAWS Lambda
New RelicNew Relic
Amazon Elasticsearch ServiceAmazon Elasticsearch Service
ElasticsearchElasticsearch
SupersetSuperset
Amazon QuicksightAmazon Quicksight
Amazon RedshiftAmazon Redshift
ZapierZapier
SegmentSegment
Amazon CloudFrontAmazon CloudFront
MemcachedMemcached
Amazon ElastiCacheAmazon ElastiCache
Amazon RDS for AuroraAmazon RDS for Aurora
MySQLMySQL
Amazon RDSAmazon RDS
Amazon S3Amazon S3
DockerDocker
CapistranoCapistrano
AWS Elastic BeanstalkAWS Elastic Beanstalk
Rails APIRails API
RailsRails
AlgoliaAlgolia

Back in 2014, I was given an opportunity to re-architect SmartZip Analytics platform, and flagship product: SmartTargeting. This is a SaaS software helping real estate professionals keeping up with their prospects and leads in a given neighborhood/territory, finding out (thanks to predictive analytics) who's the most likely to list/sell their home, and running cross-channel marketing automation against them: direct mail, online ads, email... The company also does provide Data APIs to Enterprise customers.

I had inherited years and years of technical debt and I knew things had to change radically. The first enabler to this was to make use of the cloud and go with AWS, so we would stop re-inventing the wheel, and build around managed/scalable services.

For the SaaS product, we kept on working with Rails as this was what my team had the most knowledge in. We've however broken up the monolith and decoupled the front-end application from the backend thanks to the use of Rails API so we'd get independently scalable micro-services from now on.

Our various applications could now be deployed using AWS Elastic Beanstalk so we wouldn't waste any more efforts writing time-consuming Capistrano deployment scripts for instance. Combined with Docker so our application would run within its own container, independently from the underlying host configuration.

Storage-wise, we went with Amazon S3 and ditched any pre-existing local or network storage people used to deal with in our legacy systems. On the database side: Amazon RDS / MySQL initially. Ultimately migrated to Amazon RDS for Aurora / MySQL when it got released. Once again, here you need a managed service your cloud provider handles for you.

Future improvements / technology decisions included:

Caching: Amazon ElastiCache / Memcached CDN: Amazon CloudFront Systems Integration: Segment / Zapier Data-warehousing: Amazon Redshift BI: Amazon Quicksight / Superset Search: Elasticsearch / Amazon Elasticsearch Service / Algolia Monitoring: New Relic

As our usage grows, patterns changed, and/or our business needs evolved, my role as Engineering Manager then Director of Engineering was also to ensure my team kept on learning and innovating, while delivering on business value.

One of these innovations was to get ourselves into Serverless : Adopting AWS Lambda was a big step forward. At the time, only available for Node.js (Not Ruby ) but a great way to handle cost efficiency, unpredictable traffic, sudden bursts of traffic... Ultimately you want the whole chain of services involved in a call to be serverless, and that's when we've started leveraging Amazon DynamoDB on these projects so they'd be fully scalable.

15 upvotes10.8K views

Decision at BootstrapCDN about Ruby, Node.js, Amazon S3, MaxCDN, Google Analytics, Bootstrap, BootstrapCDN

Avatar of jdorfman
Developer Evangelist at StackShare
RubyRuby
Node.jsNode.js
Amazon S3Amazon S3
MaxCDNMaxCDN
Google AnalyticsGoogle Analytics
BootstrapBootstrap
#BootstrapCDN

This is the second Stack Decision of this series. You can read the last one to catch up (link below).

I was skeptical until one of the co-authors of Bootstrap, Jacob Thornton aka 'fat' tweeted about #BootstrapCDN and according to Google Analytics, that sent 10k uniques to the site in 24 hours. Now I was pumped but I knew I was way over my head and needed help. Fortunately, I met my co-maintainer Josh Mervine at the 2013 O鈥橰eilly Velocity Conference and we hit it off immediately. I showed him the MaxCDN and Amazon S3 stats and his eyebrows went up. When I showed him the code, he was very polite, 鈥渨ell, I mean it works but I really want to try Node.js out so I鈥檓 just going to rewrite everything in Node and Ruby for the S3 scripts.

I didn鈥檛 know what to expect from Josh to be honest. In the next decision (part 3), I will go over how he completely transformed the project.

AMA below.

14 upvotes5.1K views

Decision at Algolia about React, Gatsby, Ruby, Middleman

Avatar of ronanlevesque
Software engineer at Algolia
ReactReact
GatsbyGatsby
RubyRuby
MiddlemanMiddleman

A few months ago we decided to move our whole static website (www.algolia.com) to a new stack. At the time we were using a website generator called Middleman, written in Ruby. As a team of only front-end developers we didn't feel very comfortable with the language itself, and the time it took to build was not satisfying. We decided to move to Gatsby to take advantage of its use of React , as well as its incredibly high performances in terms of build and page rendering.

12 upvotes2 comments46.2K views

Decision at Shopify about Rails, Ruby

Avatar of kirs
Production Engineer at Shopify
RailsRails
RubyRuby

In 2004, Shopify鈥檚 CEO and founder, Tobi L眉tke, was building out an e-commerce store for snowboarding products. Unsatisfied with the existing e-commerce products on the market, Tobi decided to build his own SaaS platform using Ruby on Rails.

At that time, Rails wasn't even 1.0 yet, and the only version of the framework was exchanged as a .zip archive by email. Tobi joined Rails creator David Heinemeier Hansson (DHH) and started contributing to Ruby on Rails while building Shopify.

Shopify is now one of the world's largest and oldest Rails apps. It鈥檚 never been rewritten and still uses the original codebase, though it has matured considerably over the past decade. All of Tobi鈥檚 original commits are still in the version control history.

The bet on Rails greatly shaped how we think at Shopify and empowered us to deliver product as fast as possible. While there are parts of the framework that sometimes make it harder to scale (e.g. ActiveRecord callbacks and code organization), many of us tend to agree with Tobi that Rails is what allowed Shopify to move from a garage startup to a public company.

11 upvotes597 views

Decision at StackShare about styled-components, Emotion, Glamorous, Showdown, Ruby, GraphQL, React, Markdown, StackDecisionsLaunch, CssInJs, Frontend

Avatar of johnnyxbell
Sr. Software Engineer at StackShare
styled-componentsstyled-components
EmotionEmotion
GlamorousGlamorous
ShowdownShowdown
RubyRuby
GraphQLGraphQL
ReactReact
MarkdownMarkdown
#StackDecisionsLaunch
#CssInJs
#Frontend

For Stack Decisions I needed to add Markdown in the decision composer to give our users access to some general styling when writing their decisions. We used React & GraphQL on the #Frontend and Ruby & GraphQL on the backend.

Instead of using Showdown or another tool, We decided to parse the Markdown on the backend so we had more control over what we wanted to render in Markdown because we didn't want to enable all Markdown options, we also wanted to limit any malicious code or images to be embedded into the decisions and Markdown was a fairly large to import into our component so it was going to add a lot of kilobytes that we didn't need.

We also needed to style how the markdown looked, we are currently using Glamorous so I used that but we are planning to update this to Emotion at some stage as it has a fairly easy upgrade path rather than switching over to styled-components or one of the other cssInJs alternatives.

Also we used React-Mentions for tagging tools and topics in the decisions. Typing @ will let you tag a tool, and typing # will allow you to tag a topic.

The Markdown options that we chose to support are tags: a, code, u, b, em, pre, ul, ol, li.

If there are anymore tags you'd love to see added in the composer leave me a comment below and we will look into adding them.

#StackDecisionsLaunch

9 upvotes5.6K views

Decision about PagerDuty, Slack, Go, PHP, Java, Python, Ruby, Node.js, Sqreen

Avatar of paulblei
PagerDutyPagerDuty
SlackSlack
GoGo
PHPPHP
JavaJava
PythonPython
RubyRuby
Node.jsNode.js
SqreenSqreen

I chose Sqreen because it provides an out-of-the-box Security as a Service solution to protect my customer data. I get full visibility over my application security in real-time and I reduce my risk against the most common threats. My customers are happy and I don't need to spend any engineering resources or time on this. We're only alerted when our attention is required and the data that is provided helps engineering teams easily remediate vulnerabilities. The platform grows with us and will allow us to have all the right tools in place when our first security engineer joins the company. Advanced security protections against business logic threats can then be implemented.

Installation was super easy on my Node.js and Ruby apps. But Sqreen also supports Python , Java , PHP and soon Go .

It integrates well with the tools I'm using every day Slack , PagerDuty and more.

8 upvotes16.9K views

Decision about Amazon ElastiCache, Amazon Elasticsearch Service, AWS Elastic Load Balancing (ELB), Memcached, Redis, Python, AWS Lambda, Amazon RDS, Microsoft SQL Server, MariaDB, Amazon RDS for PostgreSQL, Rails, Ruby, Heroku, AWS Elastic Beanstalk

Avatar of bpr-admin
Amazon ElastiCacheAmazon ElastiCache
Amazon Elasticsearch ServiceAmazon Elasticsearch Service
AWS Elastic Load Balancing (ELB)AWS Elastic Load Balancing (ELB)
MemcachedMemcached
RedisRedis
PythonPython
AWS LambdaAWS Lambda
Amazon RDSAmazon RDS
Microsoft SQL ServerMicrosoft SQL Server
MariaDBMariaDB
Amazon RDS for PostgreSQLAmazon RDS for PostgreSQL
RailsRails
RubyRuby
HerokuHeroku
AWS Elastic BeanstalkAWS Elastic Beanstalk

We initially started out with Heroku as our PaaS provider due to a desire to use it by our original developer for our Ruby on Rails application/website at the time. We were finding response times slow, it was painfully slow, sometimes taking 10 seconds to start loading the main page. Moving up to the next "compute" level was going to be very expensive.

We moved our site over to AWS Elastic Beanstalk , not only did response times on the site practically become instant, our cloud bill for the application was cut in half.

In database world we are currently using Amazon RDS for PostgreSQL also, we have both MariaDB and Microsoft SQL Server both hosted on Amazon RDS. The plan is to migrate to AWS Aurora Serverless for all 3 of those database systems.

Additional services we use for our public applications: AWS Lambda, Python, Redis, Memcached, AWS Elastic Load Balancing (ELB), Amazon Elasticsearch Service, Amazon ElastiCache

7 upvotes1 comment9.3K views

Decision at StackShare about Ruby, StackDecisionsLaunch, ID

Avatar of jeromedalbert
Senior Backend Engineer at StackShare
RubyRuby
#StackDecisionsLaunch
#ID

For stack decisions, I needed a non-sequential ID format to prevent users from guessing other IDs. My options were:

  • UUIDs v4 that look like this: 496a52cd-49ba-4424-99d9-344e44803cb1
  • Hashids that look like this: xpAYDx0m
  • Flake IDs whose Mastodon Ruby implementation looks like this: 101151084044583231

I eventually chose flake IDs, because IMO they are better-looking and easier to type.

Although they are meant for distributed systems at scale (think Twitter), for my feature I only cared about how nice they looked. As a bonus, because the first few bits are time-based, they "feel" like good old incremental IDs. #StackDecisionsLaunch

7 upvotes2 comments3.9K views

Decision about ExpressJS, Flask, Sinatra, Node.js, PHP, Python, Perl, Ruby, Java, C++, Piwitch, SipWitchQt, Bayonne

Avatar of tychosoft
Chief at Cherokees Of Idaho
ExpressJSExpressJS
FlaskFlask
SinatraSinatra
Node.jsNode.js
PHPPHP
PythonPython
PerlPerl
RubyRuby
JavaJava
C++C++
#Piwitch
#SipWitchQt
#Bayonne

My view of the enterprise software stack I think is different than most. I find that I use C++ and #Qt in many of the roles most used Java and typically in #SipWitchQt and #Bayonne. I also have come to adopt Ruby in those other places where I had used Perl, Python , and PHP in the past, and certainly in preference to Node.js. In particular I am starting to really like Ruby and Sinatra over Python and Flask or Node.js with ExpressJS for writing quick web api and microservices, hence why I am using Sinatra in #PiWitch going forward. I do not pick a language because of popularity, but rather based on whether I can be effective in it for the problem I am trying solve.

6 upvotes3 comments20.3K views