Live data from Hacker News

What is your current stack?

news.ycombinator.com

31–40 of 48 posts

Re: What is your current stack?

#31
At work it is Scala with Spray, that is becoming now Akka Http. In Spray you have to write your our implementation / helpers for many things as Spray is quite minimal. Scala gives your type-safety, but sometimes it feels like too much typing (say, for prototype app). So for hobby projects I started to look at Clojure / Luminous and Elixir / Phoenix.

Re: What is your current stack?

#32
post #13

Earlier quoted context omitted.

In my opinion, web technology has become so advanced that the technology for the most part should not matter as much. Unless you are doing something on the scale of Facebook or Google, your technology usually does not matter. Just choose the stack that you are most productive with. And some are more productive than others. When choosing a technology stack I look to Southwest Airlines for inspiration. I might sound st…

I have recently been going the other direction from the "Southwest model". It's on a case by case basis, but if it takes less time to learn and use a technology that is purpose built then I'll invest the time to learn / use something new. I find for some situations it's less time and effort to use the right tool for the job vs. trying to make one tool do everything.

So I by no means am talking about following the Southwest model religiously. There is always a tradeoff between over using a tool and having too many different tools in place. Ultimately you have to choose the right tool for the job. But more often than not, people tend to choose the trendy tools because they sound cool. Leave the experimentation to side projects where there is less risk involved and the codebase does not need to be maintained for years.

My general philosophy about software development is to keep things as clean and simple as possible -- and no simpler because then you wouldn't be solving the problem in the first place. So I am not suggestion that you over use (for example Jquery) to do everything in the web. What I am suggesting is to think about building software the same way that we build houses. You want to choose carefully the tools that will stand the test of time and not just the fad language or tools. For this I usually check out the community behind the software.

When I architect a software solution one of the parameters that I think about is how long will it take to get someone totally new to my technology stack up and running (and hopefully productive). Most people don't think about this deliberately and so a project might have legacy code that takes months for a new person to come to grip with. Imagine trying to recruit for this type of role. My general rule of thumb is to have the choice of tools/modules as standard as possible and aim for a 2 week preparation period for anyone to get acquainted with the code. For this reason when I use ExpressJS I stick with EJS rather than Jade. I still use CSS rather than Less or Sass (these are my personal opinion).

I also take this philosophy a step further by creating certain software patterns and try as many of the well tested patterns as possible. Thing brings consistency to the codebase.

Re: What is your current stack?

#33
post #13

Earlier quoted context omitted.

In my opinion, web technology has become so advanced that the technology for the most part should not matter as much. Unless you are doing something on the scale of Facebook or Google, your technology usually does not matter. Just choose the stack that you are most productive with. And some are more productive than others. When choosing a technology stack I look to Southwest Airlines for inspiration. I might sound st…

Southwest is a great example but lifespan of airliner models and software vary a lot. How about 80/20? Stick with one/two technologies for 80 percent and have 20 percent room to try out new things.

I tend to decide which tools to use base on how likely I would need to maintain and refractor the code. For the core application code, I want to keep things as nice and simple as possible. For particular functionalities where once you build it, you really don't have to change things I tend to use the right tool for the job. I also try to isolate the code in a way where if I am using a unique tool or unique coding pattern, I would cluster those type of code together. This allows me to isolate the unique areas in the codebase quickly and make modifications when required. Using this strategy you can use the esoteric solution in the right case and still be shielded by the technical debt that it might bring to the project.

Re: What is your current stack?

#34
Languages: C# / JS Frameworks: .NET / AngularJS / jQuery Database: SQL Server or SQLite if needed for a tiny system Tools: TeamCity / Octopus

Nothing too fancy on my end. I build standard CMS based websites at my day job using ASP.NET MVC. At home, I occasionally work with Django, but with all the news about .NET support across Linux I've put Python down and have been toying with writing C# on my Ubuntu box.

Re: What is your current stack?

#36

If I do my own REST back-end: node/express or good old php. If I go no-backend: parse.com or firebase.com (different use cases). Front-end: BackboneJS and the usual mix (CSS, HTML5, Bootstrap, Jquery, etc) and I am looking into adding ReactJS to the stack. Increasingly I am using more free/paid SAAS for services like file uploads, emails, storage, monitoring, etc. Not sure if we can call this approach a "stack" but s…

> Increasingly I am using more free/paid SAAS for services like file uploads, emails, storage, monitoring, etc. I'd consider this part of the stack -- it's just not done in-house. Can you list the services that you'd reccomend for those tasks?

While I've tested a lot, these are the ones that I actually use in prod: - AWS S3 for static storage + Route 53 for static websites - Ink (Filepicker) and Ospry.io for uploads - Parse.com for persistence and user management - Firebase.com also for persistence but for cases where auto-synch is required. - Madrill for transactional email - Newrelic for monitoring - DigitalOcean for cloud hosting

Re: What is your current stack?

#37
post #9

I worked at 2 start-ups so here are the technology stacks: The first company was started 3 years ago and our technology included: (1) Python-Flask (2) Postgresql (3) SQL Alchemy (4) JQuery for web (5) Objective C for IOS (6) Bootstrap In my second company we wanted to take advantage of the growing ecosystem around Node. We also did not want to have to manage a DB, migrations, and server scripts. Our rationale is that…

I see a trend here, I'm also solving most cases with no-backend solutions. In your opinion, what would be the downside of Firebase? Did you have to work-around any limitation? Also, did you try Backbonejs as well? Can you compare it to Angularjs? I am thinking about giving Angularjs a go but would like an opinion from someone who's already using it in prod.

Re: What is your current stack?

#38
I have joined a few startups and architected a few as well. I currently love one of the following two stacks, depending on the need:

GoLang -> Postgres -> React Meteor -> MongoDB -> Blaze

Of course, most of those are interchangeable. We use Redis for caching, Docker/Ansible for deploy, etc.

Re: What is your current stack?

#39
post #2

Depending on the frontend, I use either PHP or Node. Python is a better language and more enjoyable to code in, but I often pass my projects on to junior devs to maintain. It's a lot harder to find someone to take over a Python project than a PHP or JavaScript one. All the good Python devs seem to be gobbled up by larger companies. I'm getting into Go now, but I'm hopeful Rust will become the language of the future.…

> Elixir is cool, but I don't think I could find anyone to work on it for me.

You would be surprised! The Elixir community is growing quite fast. Come hang out on IRC in #elixir-lang on freenode sometime. Elixir also has the added bonus of the entire community more or less accepting Phoenix as the "go to" Web framework so Elixir doesn't have nearly the amount of web framework fragmentation of Go or Node.

Post reply on HN