Hey, OP here. I’ve really enjoyed your work on AI agent definitions. So thank you for reading!
I don’t actually claim that ours is necessarily the correct answer for everyone – it’s our own. But I believe it is at least _an_ objective definition. Other definitions I’ve seen have been murky and subject to interpretation.
But seriously, congrats on shipping, and for bringing some new ideas into the fold.
One point of clarification: Tines is certainly not only for the Fortune 10. We have a forever free, generous Community Edition [1] with tens of thousands of happy users, as well as a massively-discounted startup program [2] for early stage companies. Reliable workflow automation matters for teams of all sizes, and we're proud to welcome them all.
I don't have a horse in this specific race, but my life experience has been that having the source is usually a bazillion times better than "segfault and wait for support to respond" or in this specific case "send email to support to download the thing"
Ah, thanks for pointing that out! We've updated the docs to avoid referencing that deprecated repository.
FYI self-hosted is usually something that customers in highly regulated industries opt for – the vast majority of our customers are on our managed cloud.
We just shipped Groups. I'd love to hear what you think. We've been using it in our company for several months, and it's greatly improved our communication culture.
Finally, if you're hearing about Consider for the first time – it's also an email client you can adopt just for yourself (although it works even better when multiple folks on a team use together!). Overall, we've tried to design for focus and flow throughout, and almost all features apply to your own private mail just as much as shared/team-level stuff. See more at https://consider.co/.
First, it's easy to find history. With a Consider group, you can see all of the history of all groups you're in, right there in the email client. So – a new engineer, say, on their first day in the company, can browse engineering@. (And they can see all the conversations the team have pinned there, almost like a super lightweight wiki.)
Second, it's easy to browse groups you're _not_ a member of. So, that engineer can stop by design@, and take a sneak peak of what the design team are working on now and then, without having their inbox fill up with stuff they're not interested in.
Some companies (notably Stripe) have built cool internal tools to approximate these benefits on top of Gmail and Google Groups. With Consider + Groups, you get everything combined in one place by default.
We hear this a lot, and it's something I'm personally interested in. There are also a few tradeoffs and downsides involved in building it… but it's something we’re actively considering.
Yes. Rails has by now certainly crossed into boring software territory – arguably a [positive thing](http://mcfunley.com/choose-boring-technology) anyway – but it remains an excellent choice coming into 2018:
- Out of the box, Rails has close to unbeatable developer ergonomics, tooling, stability, and ease of use
- Lots of high quality, large companies use it (GitHub, Shopify, Airbnb, Square, Twitch) and have by now figured out how to scale it, often sharing and open sourcing their efforts, e.g. https://github.com/Shopify/identity_cache
- If your product front end is simple, Turbolinks can be an excellent choice (find me a faster, more bug free product than Basecamp)
- If you prefer to use a more modern JavaScript solution on the front end like Ember or React, Rails API is a perfect fit
- The Ruby ecosystem and community are both very high quality
I wonder if or when Rails will settle down and stop changing everything between major releases causing all documentation to be out of date, gems to break, developer habits to break, etc. Not to mention all of the related tooling like Bundler which seems to spit out new and uninteresting warnings and errors every time I update it.
It would be great to be able to write an application using a framework and not have to constantly change the application just to get long-term updates to the framework like bug fixes, security patches, compatibility with new versions of Ruby, etc.
Basically Rails-LTS but not from a 3rd-party (and embraced by the ecosystem).
We just recently upgraded our large Rails app from Rails 5.0 to Rails 5.1. I wanted to come back to this discussion because I'm actually astonished how easy it was to upgrade. Our project has 1,156 Ruby files consisting of 55,396 lines of actual code (per cloc, rspec and app code). Want to guess how many lines had to be updated to upgrade to Rails 5.1? 24 or 0.04%.
Django. I'm not doing software these days but still following the news etc., and it seems to me that the general knowledge of the tool is still operable since very early releases. I'm not very familiar with Rails itself but when an environment changes very quickly it's both a big distraction and a great inconvenience. I've last worked with django around January 2014, today when I look at a Django app it's the same beast but a bit better. I was also interested in node in its first days, then about 0.12 I lost my interest. Each time I look at it it's a new thing. If Rails is more like node than Django, that's a problem for a beginner, as they'd rather spend time learning fundamentals of web dev rather than learning a breaking change every month.
The upgrades have progressively become much less painful. Rails 1 to 2 was a big deal, as the change introduced the RESTful API. Rails 3 was slightly less violent, but the asset pipeline was still a pretty big deal. Rails 4 had a lot of API cleanup/simplification. A lot of meta programming magic was removed in favor of simpler code, which resulted in some rewriting of existing code.
Rails 5 was the easiest upgrade yet. ActionCable was the big change, but it’s an addition to Rails, not a replacement for some existing tech. As a result, it doesn’t disturb much existing code.
This has been my experience. I've been working on a large Rails project that started on Rails 4 beta in ~2014. Since then it's been incredibly stable and the upgrade paths have been quite simple from 4.0 to 4.1, then 4.2 and now we're on 5.0 with a few minor updates left before moving to 5.1.
Everything would have worked fine if we didn't keep things up to date, but just about everything in the software world needs to be continuously updated due to security updates/patches, etc.
In comparison to Python, where things just work for years without being touched. Upgrading can get you a better api or performance for a specific workload but rarely will it be necessary.
Intercom ● Onsite ● San Francisco ● Product Engineers
I’m looking for great software engineers who are highly opinionated about the products they work on.
Intercom [1] is growing exceptionally quickly [2], as we build out the customer communication platform. At the highest level, we’re trying to make Internet business authentic and personal for everyboddy.
Email me directly at stephen@intercom.com and let’s chat.
I thought the config error was debunked by his attorney. I think the question many people have is if parallel construction was at play and if TOR is compromised.
The FBI argument was 'leaky CAPTCHA'. The defense argument was that the application was hacked. The most likely scenario is an info leak or debug page as Ross was known to live edit/debug the application.
This evidence wasn't tested in court on 4th amendment grounds since the defense didn't demonstrate ownership of the server:
buttcoin.com reported on the leaked ip when it happened, long before it was brought up in court. buttcoin.com was bought by butterfly labs and shut down when they had their assets frozen but dailydot reported on it here: http://www.dailydot.com/news/silk-road-ip-address-leak-drug-...
I don’t actually claim that ours is necessarily the correct answer for everyone – it’s our own. But I believe it is at least _an_ objective definition. Other definitions I’ve seen have been murky and subject to interpretation.
reply