Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
HiJon89
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
7 ms
·
31.
▲
by
HiJon89
7y ago
For #5 I believe it's not just a self-XSS, but also executes on the support agents browser, allowing you to potentially exfiltrate their cookies: > Anyone can write malicious code into the chatbox and PayPal’s system would execute i
32.
▲
Tooling We've Built for Managing 3k Microservices
(product.hubspot.com)
17 points
by
HiJon89
7y ago
|
0 comments
33.
▲
by
HiJon89
7y ago
How about working to improve those take home projects since it seems to be more promising than the whiteboard interview which is doomed to suck. For example, my company has a take home project that involves hitting some APIs and doing some
34.
▲
by
HiJon89
7y ago
Engineers: coding exotic data structures on a whiteboard in a time-crunched interview is high-pressure and unrealistic! ...how about we give you a project that more closely reflects problems we solve here day-to-day that you can solve in th
35.
▲
by
HiJon89
9y ago
[Copying my reply from reddit] I can give you some background on the way we structure things in case it's helpful. We use GitHub for our open-source projects, GitHub:Enterprise for our internal code, and our engineering team has about
36.
▲
Need for Speed: Accelerating Maven Snapshots
(product.hubspot.com)
20 points
by
HiJon89
9y ago
|
2 comments
37.
▲
by
HiJon89
9y ago
Gigafactory is a proper noun referring to the specific battery factory built by Tesla; I just didn't bother to capitalize it
38.
▲
by
HiJon89
9y ago
How long will it take them to catch up with Tesla (while Tesla is simultaneously advancing their own battery tech)? And even if they can hit that milestone, they'd presumably have some amount of profit margin built into the prices. So
39.
▲
by
HiJon89
9y ago
There's good reason to believe that electric cars are the future and will soon be a massive market. I think there's also good reason to believe that Tesla has a big head start on the competition and has the opportunity to dominate
40.
▲
Lessons Learned from Last Week's S3 Outage
(product.hubspot.com)
3 points
by
HiJon89
10y ago
|
0 comments
41.
▲
by
HiJon89
10y ago
This similar to our setup with the slimfast-plugin. We use the maven-jar-plugin to add the Main-Class and Class-Path entries to the manifest. At build time, we use the upload goal of the slimfast-plugin to upload the dependencies. It automa
42.
▲
by
HiJon89
10y ago
We definitely have some dependency cruft that could be trimmed (lots of relocated copies of Guava due to incompatibilities, for example). We do frequent production deploys (of individual services, there's no such thing as deploying our
43.
▲
by
HiJon89
10y ago
We're actually transitioning from Nexus to S3 as our internal Maven repository. It alleviates disk space concerns, better uptime, better throughput, etc. We actually still produce executable JARs with this approach. We configure the ma
44.
▲
by
HiJon89
10y ago
We still use java -jar with this setup. We configure the maven-jar-plugin to construct the classpath at build time and add it as a Class-Path entry to the manifest. This is a special manifest entry and on startup the JVM automatically adds
45.
▲
by
HiJon89
10y ago
It's roughly 300 REST APIs and the rest are cron jobs, kafka workers, Hadoop or Spark jobs, etc. etc. Each part of the product gets its own API which is where most of them come from as our product is quite broad
46.
▲
by
HiJon89
10y ago
Agreed, we might not have done it if we had to resort to having the application download its own dependencies at startup. In our case, our Mesos scheduler, Singularity, handles S3 artifacts at deploy time for us. Previously we gave it a sin
47.
▲
by
HiJon89
10y ago
What was the process for adding or removing a dependency? Changing a version? If two apps needed different versions?
48.
▲
by
HiJon89
10y ago
20-30 seconds ends up being 50% for most of our Java builds, so it was a huge speedup. It also saves 20-30 seconds at deploy time when we need to download this file again. And with lots of concurrent deploys we were occasionally seeing thes
49.
▲
An alternative to packaging Java apps as fat JARs
(product.hubspot.com)
1 points
by
HiJon89
10y ago
|
0 comments
50.
▲
An alternative to packaging Java applications as fat JARs
(product.hubspot.com)
10 points
by
HiJon89
10y ago
|
0 comments
51.
▲
Upgrading to Java 8 at Scale
(product.hubspot.com)
24 points
by
HiJon89
12y ago
|
2 comments