akdas

This is another reason we need to be fighting for economic reform. Divorce will never be pleasant, but ensuring economic self-sufficiency for everyone, at least finances will be out of the picture in these separations. Another way for us to create a society that supports men.

For sure! Because this was for my own use, I need to put in some documentation for it to be useful for others. That, and pick a name :) It's all on my TODO list.

You're right: if you don't control the server, you basically can't intercept any requests without this extra AJAX call, or some similar mechanism like a tracking image served from your own server. Essentially, you need to make a request to your own server at some point!

The architecture is pretty simple:

1. Insert the AJAX request into each page, sending the page URL and the referrer in the payload. Because I found some weirdness with tools like Pocket serving my pages from some cached location, I use my static site generator (Jekyll) to embed the page URL into each page, instead of pulling it from the client side.

2. I support multi-tenancy on a single tracking server by using multiple domain names. Based on the incoming domain name, I have nginx attach an additional header to the request that says which site is being tracked. This way, I can have my personal blog and my newsletter website both tracked by the same tracking server instance.

3. Then, it's just a matter of storing the data (page URL, time of visit, referrer domain, which site) into a SQLite database.

4. And of course, I have a small web UI to view the data.

Note that I don't do anything with the IP address of the visitor. That's personal data that I don't track.

Writing it myself is what I did for my blog. The only thing I capture is the page that was visited, when it was visited, and the domain of the referrer (to see what the source is). The tracker is meant to be used for blogs where I don't control the server, such as Github Pages, so there's a single AJAX call to my self-hosted server.

I usually open source my code, I just haven't gotten around to it for this one in particular. Might be worth doing if people are interested.

100% agreed. The translation from source code to 3D visualization was ultimately based on choices we made, not on the inherent structure that already was put in place by the developer. The output was still valuable, but when the developer has a say in the output, that's when so much more power would be unlocked!

I haven't worked on the project in a while, so I can't comment too much on the current status. But I'm happy to talk about what I learned, the challenges I faced, etc. if you have any questions about those.

The multiplayer aspect is immensely valuable. Having multiple developers walk around the same codebase together, discussing the architecture and the code, is helpful for debugging, onboarding, brainstorming, all the different ways we collaborate as developers. This kind of visualization is not a solo activity, so I can see where Vircadia would come in.

> I think 3-D visualizations of 1-D languages (all our current programming languages are 1-D) will not be so helpful, as you will be looking at transformations, not the actual code as it exists.

This is the part that I disagree with. The source code is linear, sure, but the structure that ties the different components in a codebase together is high-dimensional. For example, the symbol usage graph is really useful to visualize in 3D, as is the general package structure.

And most of these visualizations we see don't even touch on runtime analysis like I was working on! There, seeing different types of data arranged either by where the data is coming from in the source code or where the data is coming from at runtime (analogous to lexical vs. dynamic scoping) is a visualization that benefits from 3D.

I worked on something like this a few years ago, only in VR so you could walk around the visualization and use your spatial recognition abilities in 3D.

One part we struggled with was evolving the visualization with the codebase. I see in the demos at the bottom that small changes to the codebase can have a large impact on the visualization (unless I'm missing something), making it difficult to treat the visualization as a fingerprint over time. I wonder if there are plans to address this.

This is an area I'm very interested in, happy to chat about it any time.

Last year, I wrote about the prisoner's dilemma of training your employees[0]. As Mark points out, many companies don't invest because they don't find it valuable. What I tried to point out was that big tech companies already _are_ investing heavily in their talent, and especially as these companies start pulling in less experienced people to train up, companies that don't invest are going to fall behind.

I don't know how convincing that argument is, but hopefully realizing how much investment the big tech companies are putting into their talent is eye-opening for some people.

(Note: I talked about investing in junior employees, but the idea applies to all your employees.)

[0] https://hiringfor.tech/2020/09/07/the-prisoners-dilemma-of-t...

Thanks! That newsletter does have articles geared toward candidates as well, though a lot fewer.

The topic of what to ask at the end is one I floated around, but I didn't find it to be a priority. In an ideal world, the questions at the end wouldn't be part of the evaluation anyway, so it should be a time for you to ask whatever you want. Unfortunately, I'm sure interviewers do judge based on those questions, so if anyone has insight into what "good" questions are, I'd love to know.

> After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better.

This has been my gut feeling for a long time, and in the last year, I finally took the time to write down my thoughts on the topic. Every week since February 2020, I wrote about some aspect of interviewing that could be improved [0], and I now feel confident there are actionable improvements to be made.

Individually, we as interviewers can shift our mindset towards looking for strengths instead of weaknesses, accommodate different backgrounds, acknowledge the best developers are not the best interviewers (both as candidates and interviewers), and put in the extra effort to hone our interview skills. At an organizational level, I'm working on training material that I hope to promote within companies that are interested in improving their hiring process.

Interviewing is thoroughly broken. But I have some ideas to make it better.

[0] https://hiringfor.tech/archive.html

You know what your job is: to figure out the problem. And the interviewer should be clear they are looking for you to figure out the problem to solve.

Absolutely, that's something I pointed out in my writing: if the interviewer doesn't explain their expectations, you can and should ask. Interviews work best when both parties are engaged heavily in the success of the interview.

Huge +1 on explicitly setting expectations. I've written on this topic[0], and there are a lot of different ways interviewers don't set expectations:

- Is the interviewer looking for syntactically correct code, or general algorithmic skills?

- For a warmup, is the interviewer looking for a basic solution, or an optimal solution?

- For architecture walkthroughs, what level of detail is expected?

The extra pressure is definitely unnecessary.

[0] https://hiringfor.tech/2020/03/02/are-you-asking-candidates-...

Looking for strengths isn't the same as lowering the bar. If you have specific requirements, you will maintain those requirements. But, the goal is to push aside weaknesses that don't matter (such as nerves during an interview, or lack of truly unrelated knowledge).

Instead, the goal should be to ensure _qualified_ candidates can demonstrate the strengths they have in meeting your requirements.

So basically, there are two pieces to looking for strengths:

1. Determine which requirements truly matter. Even for highly technical jobs, interview skills are not what makes a successful employee.

2. Find ways for those who meet the bar to demonstrate that fact.

> Everyone loves to read and write about how developer interviewing is flawed, but no one wants to go out on a limb and make suggestions about how to improve it.

I've spend this year writing about hiring[0], both to talk about the problems and provide suggestions on how to improve the process. My suggestions are sometimes high-level, and sometimes very detailed. Some examples:

- Be specific about the requirements [1]

- Tailor the requirements to the role you're hiring for [2]

- The types of non-technical issues that can cause a candidate to perform poorly, and how interviewers should correct for them [3]

- Let people work independently [4]

But above all, my primary thesis is that it comes down to looking for strengths, not trying to discover weaknesses [5]. Having been on the hiring side, this is the specific suggestion that I believe will have the most impact, especially to those who want to land a job that would have been out of reach otherwise.

[0] https://hiringfor.tech

[1] https://hiringfor.tech/2020/03/02/are-you-asking-candidates-...

[2] https://hiringfor.tech/2020/06/22/hiring-for-the-role.html

[3] https://hiringfor.tech/2020/05/25/letting-the-little-things-...

[4] https://hiringfor.tech/2020/08/03/reducing-interview-stress-...

[5] https://hiringfor.tech/2020/02/10/false-positives-and-false-...

Not saying that fitting people into a small space isn't hard.

However, children of immigrants are especially keen to assimilate into the receiving culture, so much so that they often go beyond what natives do. For immigrants and their children, a clash of cultural values may be a larger driving factor than what's the natural for people in general.

I really like that style. It's related to the Inverted Pyramid style in journalism, meaning others have thought a lot about how to get important information up to the front of a piece of writing.

https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism)

This post was inspired a recent HN discussion around GitHub and hiring[0]. I compiled some other relevant perspectives and also added my own about where GitHub _can_ fit into the interviewing process.

[0] https://news.ycombinator.com/item?id=24373633

I've been writing about this topic for the last 7 months. The absolute biggest change you can make within the confines you presented is to switch from "looking for weaknesses" to "looking for strengths". I wrote about this here during the beginning of the year[0].

You can find all my past articles[1], and I'm happy to find you specific ones. I think, given that you can't switch away from algorithmic interviews, at least make the interviews more collaborative, define your expectations up front, and generally find ways to help the candidate show their strengths.

[0] https://hiringfor.tech/2020/02/10/false-positives-and-false-...

[1] https://hiringfor.tech/archive.html

Every interview is different. You're asking people to read your mind: https://hiringfor.tech/2020/03/02/are-you-asking-candidates-...

> the compiler will guide you towards the completeness of all the functions in your codebase that match over your type. So this burden is not on the programmer.

That only works if all the functions you care about are in one codebase. If not, then the changes the article talks about become backwards incompatible changes in your library.

> So I guess these are not real problems.

If you're designing a library, the approach you take determines what types of additions are breaking changes and which are not.

> The "problem" in each case is that you have to modify code in a bunch of different places instead of one place.

And by extension, different places include ones you don't own, and therefore can't change. For example, say you have an interface in your library that consumers of that library implement. If you want to add an operation to that interface, all consumers of your library, ones you don't even know about, have to support that operation.

But, if you want to add a new interface, consumers only have to implement that interface if they want to use functionality based around that new interface.

(And of course, the same applies in the opposite direction if you're using an operation-first approach.)

I haven't fully read through the paper, but it looks like an important part of the technique is that the light acts like a point light at each point in time. For example, the projector will emit certain patterns of light, like in Figure 6 of the paper, to illuminate a localized group of pixels in the camera. Varying this pattern over time, it's possible to reconstruct how a small amount of light exiting the light source affects a small amount of light captured by the camera.

And even with "point" light sources and the parallelized light patterns, the whole scanning takes a while:

> This image is 578x680 pixels and was acquired in a little over 2 hours.

The swapped image has the same resolution as the projector, so it seems yes, you'd get a very low resolution image if you used a large light source like the sun. You can see this in the "Accidental Pinhole" supplemental video. The reconstructed image is very low resolution, but the quality is slightly better when the light comes in via a smaller area (a mostly closed window).

I actually think the other resources, including WebGL fundamentals, are really great. But whenever I tried reading them, they just didn't click for me.

I don't mind organizing the code. I just want the barebones in the beginning. I see that WebGL fundamentals, for example, uses a webgl-utils library, which is what tripped me up, even though it's only used for one small utility.

Basically, I'm still on Chapter 0 :)

100% agreed that I'll be writing abstractions as the program grows. But without understanding the underlying APIs, I don't know which abstractions to write.

As another commenter asked: what does "DSA-like helpers" mean in this case?

Thanks for the heads up. I actually did look at that reference, and in particular, the WebGL State Diagram is fantastic. Unfortunately, it still uses some helper libraries that, for me, obscure the core APIs. That said, WebGL Fundamentals is definitely going to be one of my references going forward.

I bet! I'm fortunate enough to understand the concept of shaders, and how GPUs work generally, so at least that's one concept I don't have to learn. The APIs, however, are another beast altogether.

Thanks! I'm glad the drawings were helpful.

Most of my writing can be found at my blog (https://avikdas.com/), but here are some from the same dynamic programming series:

- Deep-dive into the Chain Matrix Multiplication Problem - https://avikdas.com/2019/04/25/dynamic-programming-deep-dive... - Real-world applications of DP: https://avikdas.com/2019/05/14/real-world-dynamic-programmin... and https://avikdas.com/2019/07/29/improved-seam-carving-with-fo... - Another real-world application, this time in machine learning - https://avikdas.com/2019/06/24/dynamic-programming-for-machi...

If you look on my blog, you'll also see my recent series is on scalability, things like read-after-write consistency and queues for reliability.

Plugging my own writing, but I did a deep dive on top-down vs. bottom-up dynamic programming on my blog: https://avikdas.com/2019/04/15/a-graphical-introduction-to-d...

The follow-up posts go into even more detail on individual problems that can be solved using either form of dynamic programming, including some real-world problems like content-aware image resizing.

I've had my blog post removed from r/algorithms for self-promotion.