ninjapenguin54 (u/ninjapenguin54)

ninjapenguin54 commented on Ask HN: Who wants to be hired? (April 2024) · Posted by u/whoishiring

  Location: Chattanooga, TN
  Remote: Yes
  Willing to relocate: Yes, with relocation assistance.
  Technologies: React, Python, Django, Node, Typescript, Postgres, C#
  LinkedIn: https://www.linkedin.com/in/charles-taylor-349609133/
  GitHub: https://github.com/CharlesTaylor7
  Email: My first and last name can be seen from Github and LinkedIn. As a python formatted string: f"{first_name}{last_name}95@gmail.com"
  Resume: please email me if you'd like a PDF version of my resume. It's basically the same as my LinkedIn profile.

I'm a full stack software engineer who is effective in fast paced startup environments. I appreciate and don't stay away from challenge.

I'm a big fan of statically typed languages, and automatic testing, (both unit and e2e).

I have professional experience in the above listed technologies, but I am also to keen to begin working professionally with Rust. I generally default to building my side projects in rust these days.

ninjapenguin54 commented on Command line functions around OpenAI kadekillary.work/posts/10... · Posted by u/beigebrucewayne

roenxi · 3 years ago

Being efficient at writing code can barely make someone a 5x engineer. A team of people who write code effectively is easy to do.

Hyperproductivity in software is all about deciding what problems to tackle. Richard Hipp isn't worried about chipotle restaurant orders in golang, he's worried about how to store data reliably. That isn't a coding puzzle that ChatGTP is likely to help with. Either ChatGTP can do the whole thing itself (not yet the case) or it is a minor productivity boost because the hard part is articulating the problem.

Writing code quickly really isn't a challenge that high performing software engineers need to tackle. ChatGTP is a cool tool, we're all going to be using things like it in a few years, it'll change everything. But it won't make any old engineer a rival to the big names in software engineering.

ninjapenguin54 · 3 years ago

Good points. I feel obligated to tell you that it is spelled, ChatGPT not ChatGTP.

ninjapenguin54 commented on Ask HN: Can you recommend me a fast, light text editor for Windows? · Posted by u/supersparrow

ninjapenguin54 · 3 years ago

Neovim

ninjapenguin54 commented on Why Prefetch Is Broken jefftk.com/p/why-prefetch... · Posted by u/astdb

willis936 · 5 years ago

>That seems fine to me. Implement it and if the users don't want it then it doesn't occur. You should still code as if it works.

Please correct me if I'm misinterpreting this statement. Are you saying it is acceptable if the code breaks if prefetch fails?

ninjapenguin54 · 5 years ago

How would the absence of a prefetch break something?

Isn't this just a performance optimization?

I take the original statement to mean that worse case scenario is extra time to load.

ninjapenguin54 commented on Show HN: A Django code review bot for GitHub pull requests django.doctor/?show-hn... · Posted by u/rikatee

VWWHFSfQ · 5 years ago

It's a code-smell in Django, but I agree that this kind of thing shouldn't be "auto-fixed" by a bot. There are perfectly valid reasons why you might want to eschew the convention.

> Avoid using null on string-based fields such as CharField and TextField. If a string-based field has null=True, that means it has two possible values for “no data”: NULL, and the empty string. In most cases, it’s redundant to have two possible values for “no data;” the Django convention is to use the empty string, not NULL. One exception is when a CharField has both unique=True and blank=True set. In this situation, null=True is required to avoid unique constraint violations when saving multiple objects with blank values.

[0] https://docs.djangoproject.com/en/3.1/ref/models/fields/#nul...

ninjapenguin54 · 5 years ago

I've read the django docs. It's dumb advice parading as "best practice".

The idea that empty string and none are equivalent is distasteful.

Nobody makes this argument for int fields right? "Just use 0"?

I hate having different conventions for different field types and losing a potentially meaningful distinction between empty string and 0.

The idea seems to be born out of truthy & falsey values. (A big source of gotchas and bugs in my experience)

I'd say it's the role of django forms to clean data into a normalized form. So converting null to empty string there might make sense.

ninjapenguin54 commented on Show HN: A Django code review bot for GitHub pull requests django.doctor/?show-hn... · Posted by u/rikatee

ninjapenguin54 · 5 years ago

Empty string and none are not the same or in any way redundant. Linters belong in ci. Humans belong in code review. I can actually explain to a human why my text field has a default of none.

ninjapenguin54 commented on Rust After the Honeymoon dtrace.org/blogs/bmc/2020... · Posted by u/psanford

fizixer · 5 years ago

Rust, and Go, and Julia, and D, and Swift, and what not, should have a shouting and fighting match with one another.

When they are done, they can let me know who won and then I'll take that language a bit more seriously.

In the meantime I'm a humble coder sitting in the corner with Python + C + CUDA (plus some scheme and assembly), doing useless things like AI, robotics, IoT, etc.

ninjapenguin54 · 5 years ago

These languages aren't even try to capture the same market niches. Swift is literally vendor locked. How the heck is it next to open source runs anywhere languages?

ninjapenguin54 commented on Kosmonaut: web browser from scratch in Rust github.com/twilco/kosmona... · Posted by u/adamnemecek

dmitryminkovsky · 6 years ago

Does anyone think it would make sense to create a drastically simpler set of web standards, so that making web browsers would become much simpler?

Such a simpler web spec would be relatively fast moving, not focused on backwards compatibility, but instead on simplicity of implementation. HTML would have to be written correctly (eg. balanced tags), old styling mechanisms would be removed so that layout engines wouldn't have to accommodate them. Everything would be pared down.

I believe this would open the playing field for many people to create browsers, would breath life into the now basically empty browser space and the Web in general.

Of course adoption would be a big issue, but that's always a big issue. I wonder why this wouldn't make sense to try, given the current state of affairs. It doesn't make sense to just give up on the Web. Why not re-invent it a litte?

ninjapenguin54 · 6 years ago

Might be insightful to look at the history of xhtml.

tl;dr an attempt was made and failed. Turns out there's not enough incentive for websites to convert to your stricter html replacement.

ninjapenguin54 commented on Did George Washington Use Ketchup? (2012) savoringthepast.net/2012/... · Posted by u/smacktoward

ninjapenguin54 · 6 years ago

Catsup

ninjapenguin54 commented on Complexity Has to Live Somewhere ferd.ca/complexity-has-to... · Posted by u/mononcqc

dmreedy · 6 years ago

There is a distinction between necessary complexity and "busy beaver" artificial complexity. And it turns out that there's a pretty compelling mapping between energy and information and fundamental complexity. There's a reason they both use a concept of 'entropy'.

That said, there's no denying that there's probably a lot of unnecessary complexity in most software.

ninjapenguin54 · 6 years ago

I'm sorry without some citations this is still handwavy bollocks.

Energy does have a conservation law. Entropy does not. Not does information, complexity etc.

I majored in phyiscs, I'm familiar with these terms.

Grand parent post made no indication they were talking about essential complexity when they made their bold assertion about how it's conserved like energy.

I'm also not aware of any formal or precise way of measuring "essential complexity". Not in the way we do for energy or entropy.