Feed powered byStream Blue Logo Copy 5Created with Sketch.


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 ·
Visual Studio CodeVisual Studio Code
Graphcool FrameworkGraphcool Framework

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?

11 upvotes·5 comments·3.1K views

Decision at Shopify about Rails, Ruby

Avatar of kirs
Production Engineer at Shopify ·

In 2004, Shopify’s 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’s never been rewritten and still uses the original codebase, though it has matured considerably over the past decade. All of Tobi’s 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.

10 upvotes·323 views

Decision at Algolia about React, Gatsby, Ruby, Middleman

Avatar of ronanlevesque
Software engineer at Algolia ·

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.

8 upvotes·2 comments·21.7K 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 ·

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.


7 upvotes·3.2K views

Decision at StackShare about Ruby, StackDecisionsLaunch, ID

Avatar of jeromedalbert
Backend Engineer at StackShare ·

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

6 upvotes·2 comments·3.5K views

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

Avatar of paulblei

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.

4 upvotes·4.2K views

Decision at StackShare about Rails, Ruby, Markdown, StackDecisionsLaunch

Avatar of jeromedalbert
Backend Engineer at StackShare ·

I needed to make stack decisions accept a subset of Markdown, similarly to sites like Reddit or Stack Overflow.

I used the redcarpet Ruby gem for parsing, and Rails' sanitize helper made it very easy to only allow certain tags: links, bold, italics, lists, code blocks, paragraphs.

Problem solved! #StackDecisionsLaunch

3 upvotes·2.9K views

Decision at Gratify Commerce about Amazon SQS, Ruby, Sidekiq, AWS Elastic Beanstalk, Rails, delayed_job, BackgroundProcessing

Avatar of jeromedalbert
Backend Engineer at StackShare ·
Amazon SQSAmazon SQS
AWS Elastic BeanstalkAWS Elastic Beanstalk

delayed_job is a great Rails background job library for new projects, as it only uses what you already have: a relational database. We happily used it during the company’s first two years.

But it started to falter as our web and database transactions significantly grew. Our app interacted with users via SMS texts sent inside background jobs. Because the delayed_job daemon ran every couple seconds, this meant that users often waited several long seconds before getting text replies, which was not acceptable. Moreover, job processing was done inside AWS Elastic Beanstalk web instances, which were already under stress and not meant to handle jobs.

We needed a fast background job system that could process jobs in near real-time and integrate well with AWS. Sidekiq is a fast and popular Ruby background job library, but it does not leverage the Elastic Beanstalk worker architecture, and you have to maintain a Redis instance.

We ended up choosing active-elastic-job, which seamlessly integrates with worker instances and Amazon SQS. SQS is a fast queue and you don’t need to worry about infrastructure or scaling, as AWS handles it for you.

We noticed significant performance gains immediately after making the switch.


3 upvotes·2.9K views

Decision at Vagas about Ruby, React, Rails, Frontend, Backend, BackendsForFrontends, Api

Avatar of danilobarion1986
System Analyst at Vagas Tecnologia ·

#BackendsForFrontends #api #Frontend #backend

When we began to modernize our company's main software, we need to choose an architecture that could be as stable as it was for the last 20 years and at the same time, allow us to use one of the best alternatives to build an highly interactive and complex front-end.

So, to embrace the innovation while keeping an solid foundation, we decided to work with our main web framework Rails, with the React front-end, an amazing feature of one of Rails more recent versions.

The Ruby (and Rails) are our main programming language + framework for about 6 years to modernize our almost 20 years old legacy system. We already have a lot of interesting tools working together, like MongoDB, Redis, RabbitMQ, PostgreSQL etc. All of them with fantastic libraries/support for Ruby.

Besides that, our front-end team is growing fast, and wants to apply what they've been learning (in theory and practice) everyday with React .

But we don't want it to become a new monster after some months, when we passed the mainly features of our app to this new project, so we think: How we could use this new features? Which are the architecture that most adapt to our needs?

3 upvotes·588 views

Decision at StackShare about Ruby, Stream, StackDecisionsLaunch

Avatar of joshfng
Senior Software Engineer at StackShare ·

We use Stream to power our feed and decisions products. We hook into their api using supplied Ruby SDKs that send records to their system when we create or update them. Their personalization feature allows us to tailor the feed experience for each user based on individual interests and engagement. #StackDecisionsLaunch

3 upvotes·496 views