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/
21 karma · joined March 5, 2016
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'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.
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.
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
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.
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?
http://www2.rafaelguimaraes.net/wp-content/uploads/2015/12/g...
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.
http://on.moesif.com/cyber2016-plans
More on Moesif: https://assets.moesif.com/docs/5e47hqj
More on Moesif: https://assets.moesif.com/docs/5e47hqj
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.
(No affiliation with them, just found them through the internet)
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)
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'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.
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? ;)
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.
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