• 1 Post
  • 95 Comments
Joined 1 year ago
cake
Cake day: October 21st, 2023

help-circle





  • I know the developer of this website. It’s hard paywall. You won’t be able to bypass it by modifying the elements in any sense.

    As you mentioned in some other comments, only the currently archived ones will be available. If you are looking for just this specific article, let me know, I will archive and share the link here. If you are looking for a method to bypass it entirely, I don’t think it’s possible.

    Also I assume you are not in a position to afford the subscription. It’s fairly decent considering the quality of articles. So whenever you can afford it, subscribe and support them. Nowadays good long form articles are non existent in Indian media.



  • Hey thanks for the detailed explanations.

    Regarding SSO my concern is not the ChartDB team having my email, that I was planning to give anyway, but SSO provider knowing I’m using this tool. It’s a personal paranoia than anything else. I know it’s much safer and easier to have 3rd party SSO than managing your own authentication service. Done that, hated it. So not really that annoyed about it.

    The Mac only part really annoyed me to the core. Then I received an email telling about Buckle, which amplified it. I think the problem is you advertise it as ‘ChartDB 2.0’ and then suddenly it becomes ‘Buckle’. I can understand the thought process behind such presentations, but really don’t like it. TBH I would not be this mad if a similar tactic was used by a large corporation. But being an open source tool I have some ethical issues with these practices.

    Again, I know these are just some inconveniences, and not a scandal. So not really complaining, but just sharing how I felt. Apologies if that has been rude.


  • I have some critical comments not about the tool, but about another related stuff. Please look at the next section for doubts and suggestions.

    The tool need to be more clear and less annoying about ChartDB v2.0.

    So this is shown as some big rework, so I signed up. Only then it said only MacOS would support it initially. This was a huge disappointment and I felt kind of deceived into giving my email id I don’t remember seeing it’s only mac at the beginning on the sign up page. May be I missed.

    Another thing is it looks like a different product altogether with the name ‘Buckle’. Again I didn’t see it in the sign up section. Why a new product name? Are you switching to freemium model?

    Last but most importantly, why does a third party sign up for it? If you just want to inform the user when things are ready, just take the email and use it. No need to have access to my Google or GitHub account.


    Apart from this terrible experience, I love the tool and how it visualises it.

    I have a doubt. When I visualised my postgres db it also showed the views I had, apart from the tables. But I could not find an option to add a new view from the interface, so that I can use it as a more capable design tool. Is it a feature in the pipeline?

    Also I could not find an option to set the length of Type: varchar. I remember seeing this feature in other design tools.






  • I think I got the idea. So essentially a new copy of the file is created and stored only if there is a change, else it just refer to the older SHA. Am I right? Now I understand why LFS was needed for binaries, else it createds a lot of storage problems, but not the huge monorepos.

    I’m not a developer, but a design person who covers much more including architecture. But in my org I happen to teach developers how to use Git. Strange, I know. But that is the case. It gave me a good opportunity to learn Git in depth.

    I went through your blogs and patch stack workflow. I have to say that I have not been happy with the branching workflow and I always felt that is not the best (I agree to the point about “unjust popularity”). The patch stack workflow makes more sense to me. Unfortunately we won’t be able to adopt, since getting everyone to Git itself was a huge effort. Also developers are not that keen into creating good code, but just working working code. I’m extremely frustrated with that.

    Also your blog design is really good. I love it. I always wanted to create something like that. But never managed to sit down and do it. Can you give me a brief about the tech stack used for the blog?

    Do you use RNote for diagrams? The style looks familiar. Or is it something else?


  • Aah. I assumed linting was part of the build also. My bad. I did understand the idea you were mentioning. Just that assumptions kind of threw me off.

    I wanted to ask something related to that. As you mentioned, git takes a snapshot of the repo on every commit. So splitting up the bug fix and other activities means you have 3 or 4 commits instead of one. Let us say we are dealing with a very large repo. This does not look ideal in that context right? So do you think the way you proposed is only suitable for smaller repos?




  • So this bit confuses me. The article says in the intent and scope section that the entire process of bug fixing, in the included example, is literal bug fixing, clean up toggle, correct lints, correct duplication. That point to linting issues.

    The earlier section says that a commit should be ‘buildable’ and ‘testable’. So if there are linting issues, the commit won’t satisfy this criteria right?

    What am I missing here?