GVRV

G'day! There seems to be a major inconsistency in the listing for https://www.tigerdata.com/careers/ac8ae587-fd1d-4a3f-b844-74.... While the job description mentions "4-day 10-hour night shift from 7am - 5pm IST (1:30am to 11:30am UTC) Friday-Monday", the questionnaire for submission mentions "4-day 10-hour night shift from 11pm - 9am IST (4:30pm to 2:30am UTC) Friday-Monday". Might be worth rectifying.

Congratulations Tom!

Tom (and Fenn) had rockstar status back when I was involved in university CS+Entrepreneurship clubs in Melbourne around 2009/2010 (mostly led by fine students at UniMelb, but I was helping spread the word at Monash) because they were the first(maybe one of the first?) Aussies to be accepted by YC. They always generously gave their time and advice at these student events, even dropped by the SiliconBeach networking meets to share their experiences and turned out to be exceptionally kind human beings in person. Definitely the right choice for moding this community!

I miss StackOverflow jobs – it showed that jobs were probably published there because someone technical advocated for the platform.

Just like the author, I wanted to read and write more. As I'm taking a year long sabbatical, I just started writing (badly) at https://www.gaurav.io/blog/. The idea is to write a post every weekday (excuse the last 2 weeks – it was Diwali) even if I think it's a terrible post. The value is in getting the post published, not publishing something great, at least for now.

I'm doing something similar with reading – 50 pages minimum everyday. I've read more books in the last 4 months than in the last 4 years by just keeping the streak alive.

In my limited experience, I've seen it handled by adding the user's ID in the path of any resource that belongs to a particular user, so that the user ID from the resource path can be compared with the authenticated user ID as a security rule condition.

But as expected, you can validate the incoming data as well https://firebase.google.com/docs/firestore/security/rules-co... but this would need to be done for any attribute that might lead to a change of ownership.

Didn't they already have these rules in place? And the vulnerability was when the owner was updating the resource to have a new owner?

Congrats to the Laravel team, and Accel too! I feel they've got a winner on their hands.

Laravel has single handedly made PHP development cool again, and the way they did that was offering an integrated developer experience focused on ease of starting and quick productivity.

They flattened the learning curve of other "full" frameworks (like Django/Rails) by offering recommended (and official) tools and services out of the box. This cuts down a lot of the analysis paralysis faced by junior developers and they have an easy way to start adopting necessary complex tooling when it becomes relevant for them.

Have a look at the `Ecosystem` mentioned at https://laravel.com/ – Django doesn't have an official local development GUI or Rails doesn't have an official APM – which is a boon for power users that know how they want to setup their local development environment or what they want in an APM service, but they're exhaustingly complex choices for a web developer just getting started.

I've observed Laravel gain a tremendous following with developers here in India, I believe because of this ease of getting started and being productive quickly.

I don't even feel like the funding amount is ridiculous. For comparison, have a look at some of the funding raised by smaller frameworks/libraries (CMSes, "JAM Stack", etc) without such an extensive set of revenue making services, in the JS world.

If they continue to pour the money on expanding their ecosystem while staying true to their value proposition to developers, they will do great. I, for one, am looking forward to this next generation of PHP/Laravel-powered web (maybe even mobile with this funding?) products.

Can someone please explain why this is a high quality welding job? In India, welders are not paid handsomely and are rarely rigorously trained but I'm unable to distinguish between a welding job done by them compared to these photos.

Long term HN user @ezekg also runs this https://keygen.sh/ if that might suit your needs (i.e. if you want to separate out licensing logic from the payment logic)

I work for a globally remote organisation, so I voluntarily took the on-call rota for the last week of the year. This way, my colleagues can enjoy Xmas with their families without any pager anxiety, and they made sure I could have the same experience this past month over Diwali ;)

According to the docs, Mojo is supposed to be a superset of Python, so technically nothing will need to be ported.

Personally, I have learnt I do not have a moral compass strong enough to outweigh the consequences that come with being a whistleblower. I'm very grateful such people exist, though.

That's a good point. How would you go about solving this? Just release minimal playable demos and iterate based on feedback?

StackExchange/StackOverflow

Absolutely! It is so frickin' cool this is happening in the real world right now and it's only going to get better with time!

If you're just starting out, and want to focus on the frameworks right now without worrying about infrastructure _but_ still want something to show someone, start with replit.com

Is this US/location dependent? I'm an ACM member from India and I've not received any such communication.

I don't have anything to add to finding a solution to your problem, but I think you're not alone and a lot of people have this exact same feeling. Relevant XKCD https://xkcd.com/863/

I read a few pages and found it really good (maybe cause I was following the saga online)! I hope I get to see it on the big screen!

Ah, you're absolutely correct!

  In [4]: class Test:
     ...:     def test(self, a, b, c=5):
     ...:         return a + b + c
     ...:

  In [5]: inspect.signature(Test.test).parameters
  Out[5]:
  mappingproxy({'self': <Parameter "self">,
              'a': <Parameter "a">,
              'b': <Parameter "b">,
              'c': <Parameter "c=5">})

Then, any idea how you would address the GP's original point? How should "self" be detected if it can be called something else?

This got me thinking and I'm not even seeing the `self` being returned in the list of parameters on Python 3.8.5:

   >>> class Test:
   ...     def test(self, a, b, c=5):
   ...         return a + b + c
   ...
   >>> t = Test()
   >>> inspect.signature(t.test).parameters
   mappingproxy(OrderedDict([('a', <Parameter "a">), ('b', <Parameter "b">), ('c', <Parameter "c=5">)]))

For me, the journey started with the 'Train to Busan'!

Aren't there consulting firms that cater to this very need? The informal discussions I've heard around EB5 visa in India are that these firms group multiple such individuals and then start/run a business for this group (something like a medical practice clinic or a hospitality franchise) until they qualify for the green card, for a fee of course.

Well, because if you're using Trunk Based Development, you might as well just take backup snapshots of your code on each commit, right? That's not version control, it's just versions.

For the merge pain part of your argument, I would tell you to have a look at any successful open source project. Does it use TBD? Does it still support a big community of developers, mostly working asynchronously and shipping working software?

Now, if you're working on an internal project, please add in a bit of planning (quick note: a developer's job should not include only writing code), you will be able to ship high quality code without it slowing you down.

I'm irked by TBD because is a shortcut. It trades off deliberate collaboration loss for velocity gain – if that is the tradeoff your team wants to make, maybe you should consider it. But I do not get why experienced engineering leaders suggest using it for all teams.

I, for one, will never understand how Trunk Based Development (TBD) is considered "sane default" these days. The power of version control isn't just in a record of history, it's also in branching; and most often, I've noticed developers move to TBD because they don't understand the intricacies of their version control system and how to leverage it for a proper async parallel development workflow. You don't need to adopt GitFlow or another workflow verbatim, understand how you want to deliver software and work within the team so that you can adapt it to your requirements.

The points made by the author are confusing to me.

   Quality Assurance was under-resourced. They had a huge job of checking and re-checking every feature to verify that there were no regressions. After merging a feature into develop, they had to check again to see if there were any new issues that were introduced by bad merges or conflicting feature requirements.

If this was the case and they were fine with QA testing just the `master` branch after moving to TBD, maybe QA shouldn't have been testing their feature branches in the original workflow. Just use branches for proper code review and then QA only steps in after the branch is merged?

   The threshold of conflict was amplified by the time that passed between when a branch was cut from develop to the time when it was merged back.

   For bigger features, a branch's life could last one or even two weeks. The more time that passed, the greater divergence there would be from the other code.

Feature branches should be short-lived, as atomic as possible. And if you're working on a big feature, you have to update your branch frequently with upstream changes. Merges of Doom only happen if you're not following version control best practices.

This also requires a little bit of planning upfront (especially if you're working in parallel on a single feature), but forcing that thought is a good thing.

It also seems like they attributed moving to Kanban as only being possible due to the move to TBD, but it's not like it's impossible with a proper branching workflow.

So, the author made the switch to TBD and attributed it to increased velocity and better _overall morale_, but I think they're just enjoying the seemingly greener grass across the fence for a while.

My point is that if this is a violation and if the OP is correct that competitors are not following this rule, shouldn't Apple be transparent in its communication with OP? Why drag it out over years with cryptic responses?

Spoiler Alert: Because Apple (and Google) can get away with it.

I don't understand why people are trying to guess the reason why Apple is doing this. I'm not a fan of this concept, but I wouldn't label it as malware to be used by abusive spouses and parents.

If you read the FAQs on the website, it clearly states:

   Can I hide the Truple notification icon?
   No. Truple is voluntary use software, and is not intended (or allowed) to be used as spyware. All of our applications require a persistent notification.

And if Apple thinks this is malware or might be a legal liability, why can't it be transparent in its communication with the developer?

You can open a finder window, press `Cmd + Shift + G` to navigate to a path easily.

I know options exist, but better, more inclusive options can be possible.

Take for example messaging – Jeff Bezos uses (used?) WhatsApp, I use it, you probably use it and my relatives use it as well. No matter what the geography or your social/financial standing, you probably have access to a world-class messaging product easily.

The same is true for a lot of things: Wikipedia, Linux, Bicycles.

Why should the same not be true for wealth protection and growth? If it is possible to come up with a such a system, shouldn't we at least give it a shot?