HN user
Moesif API Analytics is an early stage, high growth start up to understand customer API usage and drive more business value.
We have multiple roles open in San Francisco and remote:
Senior Software Engineer https://apply.workable.com/moesif/j/86483B715B/
Enterprise Sales Development Representative https://apply.workable.com/moesif/j/5E13A09868/
We at Moesif (https://www.moesif.com/solutions/track-third-party-api) released a similar tool in 2017 and found that many of our customers including Deloitte, UPS, Snap Kitchen, iFit, and Trung's previous company, Snap Kitchen were looking for a way to track APIs without the complexity of a full service mesh like Envoy. Especially if you're hosted in something that cannot run an on-prem service mesh or gateway.
We're a little different in that we also support agent-based rather than just proxy. Meaning we have an SDK that sits out-of-band.
Ah, sorry about that. Looks like I can't edit anymore :(
I prefer REST especially for public/external APIs. It's more empathetic towards third party developers who may not be as intimate with your API as your internal team. For example, much easier to reason a few well-understood entities like items, users, and orders if I was building an e-commerce API then a list of RPC operations. I would add GraphQL can also be easier to understand as long as the entity relations make sense. Lot's of exciting stuff happening in the GraphQL world but it does have disadvantages also.
Interesting to switch away from a static generator due to reliability. We used Tumblr for our first start up since many non-technical folks were writing content (It was a consumer app). We had a bad experience with it being slow loading for users while being very constrained regarding the theming and clunky editor.
Our current startup is much more dev focused (API analytics) so we went with Jekyll and absolutely love it. Just code in Markdown and your favorite editor and host on GH pages. It's free and super fast. No need to worry about theme settings everything is version controlled. These days, even if you need dynamic content like search, you can use Algolia or Lunr if the index is small.
I guess once you hit a point where you have a large team writing and scheduling content to be posted, static generators may not scale well accordingly (and Ghost will prob be one of my first picks), but we love it for smallish dev focused teams.
LOLOL
Moesif | API Analytics for engineers and developer relations (https://www.moesif.com)
Onsite in SF or Bay Area.
Required Skills:
- Passionate about the API economy and serverless computing
- Experience working on modern backend systems and frameworks using languages such as Scala (preferred), Java, and functional languages
- Experience working with large installations of Cassandra, HBase, ElasticSearch, or similar
- Familiarity with Spark, Storm, Kafka, MLlib, Docker, and other open source technologies
- Building highly scalable REST APIs and data processing pipelines.
Helpful skills:
- Experience working in a modern cloud provider like AWS, Azure, or Google Cloud
- Familiarity with current APM and logging tools like New Relic, Sumo Logic, or Splunk and mobile analytics tools like Mixpanel/Amplitude (Our customers call us the "Mixpanel for APIs")
- An eye for ensuring secure systems
- Awesome at the Unix/Linux command line.
Moesif is a VC backed API analytics and monitoring service founded by MIT and Michigan engineers with deep expertise from Intel/Microsoft/Zynga.
https://angel.co/moesif/jobs/169518-founding-software-engine...
Please send your resume or drop a note to derric@moesif.com
Second Hubspot, great for SaaS companies that focus on inbound marketing. The CRM product is free. If you're a startup, they have a program to get 90% off their other products.
Whatever CRM you use, look for one that integrates with any customer related tools that you're using. Larger players like Hubspot can attract more developer integrations. For example, we use Drift (Like Intercom but much cheaper) for customer support and sync events in Drift to Hubspot.
They seem to be in a unique position to monetize with multiple models. Compared to something like Github, Docker and Docker Swarm has much more opportunity for large enterprise support contracts. Most companies feel that Docker is synonymous with containers, yet still don't fully understand the technology. Git already had a high adoption years before Github was around so developers were familiar with it (or other VCS) and didn't need to spend thousands of dollars to support a git repo.
On the other hand, curious how much revenue DockerHub is bringing in and where they will plan on taking it. That model seems closer to Github. Will it be a newer way to discover new OS or even propriety images like how devs use Github?
Damn that sucks! Just searching for Spider Search Analytics LLC brings up so many patent cases.
I like to always try to automate stuff as much as possible to remove human error. It's easy to forget an arg or other parameter on a script or even know what the arg was for in the first place. Sounds like their last backup was 24 hrs ago. Having backups are like having good security, you don't realize how important they are until it's too late. Reminds me of this old meme:
http://www2.rafaelguimaraes.net/wp-content/uploads/2015/12/g...
It's definitly interesting to see them move. Google already has Google Analytics/Firebase Analytics which pretty much every app developer integrates given their generous free tier so the extra data seems to be diminishing returns for Google. Seems to be more of a loss for Twitter than Google's gain given now they won't have a GA like equivalent.
I don't think Fabric was ever used for Twitter ad targeting just by reading their TOS unlike the Google/FB world and their analytics products but I could be wrong. Seems like a case where Twitter didn't realize the full potential of Crashlytics and Answers.
Yea, same here :( Although they do have Wildcard certs for $20 bucks now. Problem is you need to activate by end of Jan.
Moesif is offering over 50% off on yearly plans for their API debugging service today.
http://on.moesif.com/cyber2016-plans
More on Moesif: https://assets.moesif.com/docs/5e47hqj
Moesif is offering over 50% off on yearly plans for their RESTful API debugging service today. http://on.moesif.com/cyber2016-plans
More on Moesif: https://assets.moesif.com/docs/5e47hqj
I see it also!
The economies change a lot when you can book that revenue up front. Many SaaS startups want to lock in year long contracts even if the total amount is less for this reason. That revenue can then be used to pay salaries, etc. Not everything has to be or should be paid by VC dollars.
Nest may have figured they could build a larger ecosystem in the IoT and Smart Home space and charge monthly at some later point but didn't materialize.
This is pretty good, searches FB, Twitter, etc also if you want to see if those usernames are available.
Assuming an external/public one is OK?
Uptime Robot is free, and does it well.
(No affiliation with them, just found them through the internet)
It really depends on the context... the valuation, latest 409A price etc. It's not that one is necessarily better than the other for all cases. You wouldn't want options at Intel or Microsoft since there may not be enough upside to see any delta from the strike price. (and companies can't give artificially low strike prices due to recent IRS laws around fair market value from 409A valuations). For a smaller private company, your strike price may be a third or half of what the last preferred share price is depending on stage of company, etc. With options, you're incentivized to increase the value of the company. On the other hand, RSUs are not usually used as an early employee at a startup since (assuming they are a RSU grant) RSUs are taxed as they vest. With startups having rapidly rising valuations, you would suddenly owe tax on something that is still illiquid. The company or employee would have to pay this large tax. Something not easy if you're a cash poor startup.
Apple Music (with gift cards ;)) DashLane Namecheap Dropbox (surprised haven't seen this yet) Github
Some interesting points. Sales risk seems very focused towards enterprise sales, but I believe having a go-to-market strategy is more important than just having the ability to hire experienced salespeople. Some products don't even need sales people, but the channels, partner platforms, etc should be identified. Does this product rely heavily on inbound leads, require SEO or content generation, etc?
Also, certain risks inherently trump others for early stage startups. Moving from a 3 to a 5 under Product/Market Fit is a much more ideal compared to moving recruiting risk from 1 to 3 or team risk from 1 to 3. (After all, it's kind of moot to hire full time employees for every area if you don't even have good P/M fit)
The Node CLI is pretty good. Almost does everything the Powershell CLI does and works across platforms.
Their web portal is a lot better after they moved to the new "preview" one. The classic portal was pretty bad, but their transition from the classic to the new portal was even worse. There was a time period where certain operations were only available in the classic portal and other services were only available in the new portal. The transition took many, many months (maybe a year) and the new portal was initially very slow.
If you look at Google Cloud's and AWS admin portal, they are not really any better. Probably is a result of these cloud providers providing so many services, it's hard to organize it all. The others have faults also. For example, I hate how AWS does their form validation when creating new resources. You don't even know what's wrong until after clicking "submit" / "create", azure is more single page app like. With AWS, if the service you are creating requires a dependent resource like an s3 bucket for logging, you have to go create that dependency first. With Azure, you can choose to use an existing dependent resources or create new ones all in a single operation. There also seems to be less organization in AWS. With Azure, I like how Azure does their directory structure of sub panes. You can view all services at once with particular ordering like datacenter region or drill into a particular resource group or service type. With AWS, you always have to go to that particular service's "website" whether S3 or DynamoDB, etc.
I agree sounds more like the contacts were imported through app permissions or something, unless LinkedIn found a real venerability in a common browser or leveraged some CSRF or XSS attach, but seems doubtful given it's Google. It's so easy just to accept the laundry list of permissions for common apps.
I'm doing some email outreach through Hubspot which requires access to my gmail so I set up a separate email so they don't have access to my main account. I don't believe Hubspot will do anything with my offline access token, but it's just one more system that has access, so better to follow the whole principle of least privilege.
Spaces always. I just always program vimrc or editor's config to auto insert a certain number of spaces divisible to some number like 2 or 4.
IMHO thought spaces were always recommended to ensure formatting is consistent across multiple environments so never read too much into the spaces vs tabs on SV TV show.
A lot of coding guidelines like Python recommend spaces.
Next on SV, Vim vs EMacs? ;)
Any thoughts on what people thing? What do you use, local storage or cookies?
Scala is definitly a cool language to learn. I like the type safety in statically typed language, and Java is just too verbose.
Scala + Play Framework + Akka is solid. We use scala for parts of our pipeline for https://www.moesif.com
Docker is definitly up there also with Docker Swarm/Compose, etc. Just a matter of time as Docker Cloud and the whole Container as a Service area is fully matured. I like Kubernetes on Google or Docker Swarm on Azure, but still a ways to go before it's like spinning up a Heroku like instance. They are one of the few companies able to execute very well in getting people to adopt a new technology.
Nice to have it directly in DropBox since folks probably already have their PDF there anyway. No need to separately upload to DocuSign, HelloSign, etc.
Under your TLB section, you mention: "The TLB is a cache for the MMU. All memory in the CPU's L1 cache must have an associated TLB entry, and invalidating a TLB entry flushes the associated cache line(s)."
Many CPUs such as x86 ones don't actually flush the L1 on a TLB eviction, there would be no reason to. Eventually the line will be evicted through a snoop, capacity eviction, C6 transition etc. Of course, if a later memory access comes to re-read the line, the TLB will have to be repopulated in order to have a mapping.
Also, on the "appeal of huge pages", I would put what are the negatives. Huge pages have appeal of reducing TLB pressure for stuff like big data/HPC workloads with large contiguous data sets, but it can also increase page fault latency and memory usage for more fragmented workloads that touch many pages. For example, on persist, Redis forks a process that may touch many pages. Each COW would have to find room for and allocate 2MB rather than just 4K