jabzd
jabzd on Hacker News
We actually had it that way on accident in a few of our applications - we had a `#isTextable(e164)` function that would do a carrier lookup and voip carriers sometimes returned as landlines or as arbitrary values that didn't mean mobile. We eventually did some work to refine that function to be smarter and actually better represent if the number was textable. At least for us, it wasn't a conscious decision, it was a gate being aggressive in our SMS pipeline.
Yes, can confirm I am seeing the same behavior. Other members on my team in other regions are able to resolve addresses - seems to be hit or miss to a degree based on location.
This is exactly what we do as well and the approach works pretty well. We also tag the associated git repo with a build id and branch name so by looking at the git repo, you can tell if and when something has been built.
It was a preface to that list, as in "if you don't solve this one, don't bother reading the rest of the list." That makes it the most important thing...that's how I read it anyways.
I consider it "serverless" similar to how "stainless" steel only lessens, but isn't a full 100% guarantee. That makes me feel slightly better about the term, ha.
For what it is anecdotally worth, this has gotten better. It launched in Chicago at least a year ago and the first few orders my wife and I placed, I felt like I should have shopped myself for how many items weren't found and how much hand holding the shopper needed to replace items. We almost gave up on it, but with a baby in the house my wife kept with it and the replacement feedback loop has really gotten much better. Nowadays, out of a 25 item order, maybe 1 item is replaced and usually without a back-and-forth necessary (something reasonable is picked and you have the opportunity to reject it). Also, luckily, in the Chicago market most of the stores are "same-price-as-in-store" and the prices seem fairly reasonable where I mostly believe that.
I felt very similar. Especially thinking about it from a disaster recovery/re-bootstrapping perspective. That scared me into using docker swarm kit which is stupidly easy to bootstrap. Keep in mind that's not necessarily a like for like replacement but it was enough for my use case.
I've been keeping an eye out waiting to feel more comfortable to use and support a kube cluster on bare metal.
90% iOS app development, 10% familiarity.
We're a small shop so we have one team that does everything so one machine for all contexts is starting to be a pain. We did at least dust off some mac minis to do puppet (lots of virtual machines) work on those when possible to free up some RAM on our app dev machines.
Totally agreed on the value-add for those languages. We'll probably keep one license around for the times we drop into Java for Android which is fairly infrequent. Otherwise, we're a mix of JS (NodeJs/React/Appcelerator/etc), Ruby (via Puppet), HTML/CSS, PHP, Python, etc. IntelliJ was overkill in the first place but the one IDE to rule them all is just too compelling to not give it ago. Worked for 2 years, the product has just gotten too slow now.
My gut reaction is that IntelliJ's indexing isn't yet properly optimized for the small-file dependency-hell that JS dev has turned into.
The unfortunate thing was that we were willing to upgrade to the newest Macbooks if they had 32GB of RAM and hope that helped (in addition to some VM woes for working on infrastructure) - probably would have kept IntelliJ in play but the swapping and it using 33% of RAM on our machines made it an easy target to try to replace.
In comparison, VSCode is using 70MB RAM on my machine currently with 6 projects open.
I was at 600% CPU and 5GB of RAM with 3 project windows open, for IntelliJ Ultimate (we hop between a lot of languages so this is easiest). This was with most inspections turned off!
I've also moved to VSCode and haven't looked back. My whole team is currently evaluating VSCode. That is ~$600/mo in subscriptions to IntelliJ Ultimate if everyone decides to move to VSCode - which is looking likely.
In Chicago, some recruiters have started asking for 30%. I've refused to work with these companies but rates are definitely going up.
We are currently moving to using Docker swarmkit (from non-Docker environment). We thought about using tags to communicate environment but it felt like an anti-pattern given how tags work. What we ended up with is the following:
Per publishable branch (e.g. master to prod, dev to QA, shared integration that isn't ready for dev to secondary QA):
- Publish image to private docker registry with tag in the format of <branch>-latest (e.g. master-latest, dev-latest). Also add labels with git revision hash and CI build number to reconcile what is in the image both in CI and in git repo.
- Capture the digest of the published image and put in .txt file as an artifact from CI.
- Add a tag to the git repo with the build number, treated as version number in the form of v<build-number>-<branch> (e.g. v1-master).
- Maintain list of applications' docker image digests that should be running in each environment. We currently have this automatically determined by pulling the digest artifact from the passing-build digest. We do allow for manual overrides, however.
- We have a CI project that updates the docker swarm with these digests and other settings (replicas, mounts, environment variables). We wrote a small tool that does this similar to where stacks/dab files are going but with more functionality.
With the labels and published digests we can go from build to digest, digest to build, etc.
This is working really well so far and we aren't fighting the tools. We may separate the non-master registry later in life, and that's really easy given that docker treats the private registry hostname as part of the tag.
In one keynote I went from being excited about what was coming to feeling held hostage, yet ignored, in the Apple ecosystem due to iOS app development. 16gb of RAM is just too limiting for some workloads.
I may need to outfit my team with powerful linux desktops and low end macbooks for app development and remote/emergency work.
Pertaining to your edit, apologies for over-simplifying originally. You are absolutely correct that the Security Rule is very very vague. Many HIPAA audits barely reference the Security Rule and instead use stronger rule sets. Unfortunately, HIPAA is generally documentation of policies as opposed to true technical guidance and requirements. We're also an 8 year old SaaS company so many of our agreements pre-date the "cloud" catching up from a complicance perspective. At the speed of healthcare, I imagine it'll take another decade for the industry to realize that an AWS cloud is probably more secure than something a 10 person organization can cobble together.
Not so much HIPAA directly, but the business associate agreements that many customers make use of. In order to meet the requirements of many of the agreements we have in place, we have to own any and all hardware that PHI data lives on. They don't exactly accept redlines on those kinds of agreements.
Unfortunately, many standard business associate agreements with clients have yet to catch up to cloud offerings having better compliance guarantees. Many of our agreements with customers, both more recent and legacy, are the reason for the requirement.
We're in the healthcare space so we have to own our hardware and co-locate. Being a small outfit, sometimes it's so frustrating trying to find the right resources online these days related to racking and configuring your own bare metal! I can definitely appreciate the 6 weeks to 6 seconds. We recently added a new database server because we were really struggling at peak times. The 5 weeks it took between ordering the $25k server, configuring base os, racking it, replicating current data to it, and then choreographing the switch was brutal. Due to the nature of our product, it had to be a zero-downtime switch. Somedays, I wish it was as simple as clicking upgrade instance on AWS RDS. Other days, I make myself feel better by calculating the thousands I'm saving a month.
Mine is 8763 UNTIL DICK, word list definitely needs a review.
We've been holding out to leverage 1.12 at my org for simplicity purposes. We only have ~25 bare metal nodes, in a weird middle ground where bootstrapping and managing Kubernetes/DCOS/etc are a bit much but single node docker-compose is too little. The supposed ease to add/remove nodes as swarm workers is very compelling for recovery and maintenance purposes. Basically, complicated enough to solve problems we have and not overly complicated where it creates problems we don't want. Now to give it a try and see if that holds!
I'm in a very similar role here in Chicago and very interested in this kind of group. Feel free to reach out at jbzdawka (at) gmail.com.
I think August Lock would even take the need for an API away, just need to manage users via existing features. I think it even lets you timebox if you only want certain employees to have 8 - 5 access vs 24 hour access.
However, it'd be an extra step and not integrated with some central employee list so the risk of forgetting to remove someone may be too high if using existing features, so that point may be moot.
401(k) is something we are planning on early next year, yes.
As for the seven years in with 10 employees, definitely valid point. However, I always make sure to point out to candidates that we were 3 employees 2 years ago and are now getting significant traction with bigger clients. We are in an extremely slow moving B2B industry so it takes significant time to get that initial traction. It is very much a referral based sales process and potential customers like to bucket themselves based on size. Effectively, we've had to work our way up the food chain to get to the bigger fish. We expect to be 20 by the end of next year, so it carries more weight now than it would have 2 years ago. This is the same reason we even foresee a sale event in the next 2 - 3 years with the growth we've had over the last 18 months.
Perhaps that's stockholm syndrome speaking (kidding) :p
We are a 7 year old company. I have only ever had one candidate find a problem similar to the point you are making. Most understand that the risk profile makes a world of difference for a profitable company now versus 7 years ago where skipping payroll for the co-founders was common.
Your math is slightly off in assuming that the .1-.25% carries for the bulk of the ten, but your point valid all the same as a potential concern for individuals.
We often struggle with being labeled a startup due to our age and risk profile, but due to our size, we accept it! Ha.
Absolutely and totally agree on all points. Your $50 million is the exact number and breakdown (except on a 3 year timeline) I use for candidates that have made it far enough into the interview process such as having an offer on the table or have asked during the process how we approach equity.
> In today's market, your best employees can probably get 50-100% of that hypothetical annual bonus in real cash just by switching jobs.
I did not mean to imply that is the only bonus plan. Cash bonuses and significant raises generally yield an additional 20% of pay over the course of a year. We absolutely have to combat the switching of jobs yielding that in raises, especially as we are a software engineer heavy organization.
It's more that we don't want to not offer stock grants/equity at all just because they suck or are a lotto ticket. Especially in order to reward long term employees in an additional way. We more or less say "here's this lotto ticket, pretend this doesn't exist for now." The retention aspect may kick in if we appear to be nearing a sale event, but on day one means nothing.
Absolutely. I'm a co-founder of an less than 10 employee company. I make sure to make it clear that our offered restricted stock grants (that are between 0.1 - 0.25% at this point) are not replacements for compensation. They are instead bonus/retention plans that act as a bite of the apple if the company were to sell and they are still employed by us. Otherwise, salaries are intended to be at or above market.
In other words, I care more about getting good talent with those "realistic worldviews" than attempting to pull the wool over the eyes of those that get caught up in the type of thinking of planning purchases when they win the lotto because they bought a ticket once.
If only more startups worked that way, instead of leveraging those types of individuals to get more hours at below-market pay because everyone is an "owner." It's almost criminal...
Haha, fair enough. We appreciate the input and sanity check.
Also, this can be more helpful for earlier stages of an idea where you may be trying to determine initial steps for implementation, cost, feasibility, etc. You most likely are already at an MVP if you are posting to HN. We are more than willing to sink our teeth in earlier and protect your speed/stealth to market (stealth assuming a paid report).
We don't use Vagrant for an easy to setup dev environment. It's for two main reasons:
1. Consistent environment across all developers, even in my case which is only 4 devs. One person being a version ahead on node could cause problems.
2. The same environment as production. Getting rid of almost all problems that come from moving from dev to qa/staging due to environment change has been a god send.
Of course it's going to take awhile to setup. It seems like the main argument to push away from it is time spent on setting it up, but this article even says setting up MAMP can be difficult at first. Ever tried to get MAMP to work with non-standard PHP extensions? Good luck. apt-get install php-redis is much simpler.
You do need buy in from the whole team to really get the time out of it, but that seems like a problem with tool consistency across the team - nothing to do with vagrant specifically.