tdondich

Pretty awesome move by the bunny team. I've checked it out and I really like the interface. But one thing I really like is the scripting ability to script DNS responses. Good choice opening this up in the product portfolio, even if you still need to use $1 a month in spend in order to support this.

That being said, their monitoring is a little light. I'm the founder at DNS Spy and having an external tool that can monitor your DNS service as well as identify problems when it comes to your DNS record configurations plus additional security checks and phishing domain detection.

Take a look at our write up about Bunny's move. Congrats to the team.

https://dnsspy.io/blog/bunny-dns-free-review-monitoring

Thanks! It helps when you've built a lot of foundational stuff to build it on. Honestly at this point it was more about the UI than inner workings.

I wanted to build a platform for people to instantly create a chat room and share it with others with absolutely zero user registration. Think enabling quick conversations around popular topics. There's no user registration so no tracking necessary. Think of it almost like IRC for the web in a clean format and easy to share. I'm considering this a public beta so people can try it out and give me their honest feedback. I'm hoping this is something that people would find really useful so they're not communicating on platforms that require a bunch of hoops to get through. Would love to hear people's thoughts!

I'm the CTO at ProcessMaker and so I might be a little biased. Our customers use our ProcessMaker BPM product if the workflows require human intervention through forms/email other interactions. The reporting tools assist in monitoring and dealing with circular chains.

If you are a developer and want to develop your own system around a workflow engine, we also have www.processmaker.io which is a workflow engine in the cloud. So all the infrastructure hassle is taken care of for you and you communicate via an api to build out your workflows and execute them. I feel like that's better described as an orchestration engine however it supports task assignment to people. An approach like this works well with microservices since it can act as a microservice orchestration engine with a more human workflow approach.

Both of these approaches can be long running (some customers have year long processes running).

Let me know if you want to know more details, happy to share.

A lot of it may be information leak worry. You want just your data to be stored and some workflow engines require more than what is needed to make a decision.

We actually are releasing a use-case video that shows how to keep your data local and still be able to use a workflow engine in the cloud keeping your data local while making decisions and orchestration external.

Ah no. The company is that old and our main product is at processmaker.com. The copyright that you see is tied to the company name. Probably something we should correct/clarify

This project is brand new and we were working on it now for almost a year just now releasing it into the public.

For your type we actually have an open source full bpm solution at www.processmaker.com. It's a full bpm workflow suite that you can run on premise. Open source and enterprise support available. Pm.io is purely a lightweight workflow engine specifically for isvs and developers for embedding functionality.

Now we are considering also providing on premise and private cloud deployments for enterprise customers for this specific platform too.

The support matrix for TLS can be found at: https://www.ssllabs.com/ssltest/clients.html

Hi feross. Please note that Android 4.4.2 (KitKat) does support TLS 1.2. As you can see at http://www.appbrain.com/stats/top-android-sdk-versions (A good gauge of android distributions), KitKat is the most used Android distribution, followed by 5.0 (Lollipop). So, the actual percentage you are looking at is ~25%, but that's also for the native Android browser. Note that the API kits for these versions actually DO support TLS 1.2, when you look at the documentation for http://developer.android.com/intl/zh-cn/reference/javax/net/.... , you can see this is supported in SDK 16+ so custom apps most likely already use TLS 1.1+. Now, we know this is hard. We know some users will be impacted by this; however, this is how security moves forward. We will continue to monitor our customers and work with them hand in hand to make sure the transitions are as smooth as possible.

Not sure if you watched the video or not. The advice, in context, described what happened after my first startup failed. The first startup was recognized as a failure and I had to admit defeat and let my staff go. This is, to your point, acknowledging when it simply won't work.

However, the message of "Quitting is Lying to Yourself" is that if you have the spirit of an entrepreneur, telling yourself that you'll never do it again is lying to yourself because you know you will find a passion and feel the desire and need to build something new.

Thanks for the comment! You know you're an entrepreneur when you get hit hard cry it out and get back up.

Hey there! Answered on our blog, but also wanted to post our response here as well:

Hi Matt! Great question. There was prototype code in both GO and Node.JS. The code written in GO was not fully tested in a "production" environment because we made our decision on quite a few factors early on.

GO is fantastic as faster development cycles and performing CPU-bound operations. However, there are places where GO just isn't the right choice for this particular scenario.

We use GO in various parts of our infrastructure where the piece is small and meant to process lots of information. However, provisioning zones is not so much a CPU-bound operation but an external operation bound operation. We have to wait for nginx to do various operations before control comes back to us. We're not crunching numbers, we're writing to the data storage for our provisioning information. This type of operation is further bound to external factors.

GO is also a language that doesn't have massive adoptability yet. There's a lot of 3rd party vendors where we use their technology and rely on their SDK's to interact. Many of those vendors may not have written a GOlang library. Sure, there's bindings to other languages; however, this is a small hoop to jump through. Is our provisioning dependent on such libraries right now? Not so much. However, you have to keep an eye on the long-term future.

We also isolate our backend systems at various levels and have them communicate via REST API's. You can certainly write solutions in GO to have a REST frontend; however, it's not the ideal case for GO, in our opinion. There's a fair bit more scaffolding to put in place which means more code to maintain. There are some some great libraries out there for this (check out https://github.com/ant0ine/go-... however, we have to compare the amount of code we need to write to support the environment we run in, versus the amount of code that focuses on the core problem we are trying to solve.

Also, it's pretty difficult to find GO rock star engineers to hire. We have a couple amazing ones here in our team and we only hire the best. By the way, if you ARE A GO rock star, we want to talk to you. Reach out to me.

So, what we really wanted to find was a replacement language that is quick to develop, does well with asynchronous operations, which are external operations and I/O bound, and is easy to maintain with our existing engineering team as well as future members.

When deciding what platform or language to use to solve a customer facing problem, you sometimes can't make the decision on numbers alone. In the end, node.js has the right balance of features to give us the ability to rapidly develop solutions that are I/O bound and has the support and maintainability to ensure we can keep developing the best customer solution possible for this specific use case.

Heh, I'll need to put in a character limit. Thanks for the input!

The old server crumbled due to unexpected popularity. The new one should be a bit more stable. Thanks for helping!

I've moved the server to one with more resources. It should be back up now. :)

I'm moving the server right now. Will give an update.

Yep. That didn't take long!

Restarted.

Yes. Please do. taylor@urshoutbox.com

A bit, but more available to people and quick to share.

Hi Steve,

I also have a language learning startup at http://www.nihongomaster.com which is targeted purely for Japanese learners. Your post is an interesting read because I've gone through all the phases you've detailed. It's a uphill battle but overall a great experience.

I emailed you so we can keep in touch. I think entrepreneurs in the language learning space can help each other out and encourage each other to succeed.