Hacker Newsnew | past | comments | ask | show | jobs | submit | moray's commentslogin

On aliexpress for very cheap search for "DT3 Data Cable Detection Board Type-C". I got the one below and seems to work fine for what I needed.

https://fr.aliexpress.com/item/1005007509475055.html

Edit: This will test whether the cable is functioning properly. It will show the connections and indicate whether the cable supports only power or also data transfer. However, it won’t provide information about the USB-C cable type or its speed capabilities.


Thank you, I didn't know this bit. I always believed that great comedians are also the best communicators


That's a nice little project that I would use to quickly build an API for testing or developing an app, you just need the php executable to start it up.

But if I had to make one comment, after looking at the code, that serve function with that huge try/catch block is not the nicest thing to see, I would split it up and try to get some more meaningful exception and error handling.


The "Chlamydia" one reminded me of the movie Antiviral, where people with celebrity obsession can buy a virus/illness sampled directly from their favorite vip.

edit, link: https://www.imdb.com/title/tt2099556


Such a good film!


That is called Class in CSS...


This is all so played out now.

People that haven't used Tailwind come along and say, "this is silly, just use css". The people who have used it say, "you should try it, it's not what you think."

There are a bunch of subtle differences with Tailwind that make it quite a different experience.

Really, it's closer to inline-styles++ than anything else. The style only applies to the element you're styling. This is by design as it means you can change that one style without wondering what else you've broken across your app.

But you get variations that inline styles can't do (and aren't fun to do in css either): `text-green hover:text-red dark:hover:text-white` (interaction states, light/dark mode, responsive etc etc). This makes a huge difference when you're actually building this stuff.

Personally, from a DX point of view, I really like it. I find it faster than anything else when I'm building and it's easy to debug too; no need to fish for the styles, they're inline on the element I'm styling.

The biggest wart is the inability to functionally build up styles. For example, you have a bunch of js and you need to flip between several different colour states (say for an input that has "disabled | errored | valid | pristene"). There's no great way to force one of your classes to "win" because they're all just classes and the way they were added to the page will determine which border colour wins, for example.


"Sender" refers to the domain, read it as: the sender domain policy allows X and Y servers to deliver emails for this domain (or subdomains). But I agree that is confusing, also I was unaware that only the HELO and MAIL FROM in the envelop are used, I should check my postfix config..


Right, the "Sender" in SPF is the Originating Entity (domain/domain owner), which defines a policy to explicitly bless a set of mailhosts allowed to send messages on behalf of users.

Posted article uses "Sender" for the user, not the entity. Authentication inside the entity is the entity's responsibility. SPF is only concerned with verifying that the mailhosts offering to deliver messages on behalf of entity are allowed to do so.


I am in the same boat and I was just thinking about it after upgrading to a Mac M1 pro. One plus point for Firefox is the dev tools, especially for grid and flex.


Well...

https://www.npmjs.com/package/is-odd-or-even

that of course depends on is-odd and is-even.


There's still room for an is-odd-and-even package.


what happened between the 22 and 28 of December 2020? Almost 20 million downloads...


Christmas?


Sounds like a joke, but probably a lot of people got new computers and rebuilt their npm caches


Advent of Code?


I totally agree and I hope they will remain external packages. My workflow does not use/require any of them and I am happy as it is. What it looks like Livewire is trying to solve is having a "reactive" way of doing things without touching javascript and by elimintating the need of implementing an API. I understand the need of consolidating the dev process to one single language and siplify it but there is a reason why we separate backend and frontend.


I went down the rabbit hole of trying to minimize client side JS usage for web applications and interactions on websites with these kind of paradigms. I understand where it comes from and at first seems like a good idea. I tried prototypes, different libraries, tried to roll my own solutions etc.

What I found is that this is a good idea in _some_ contexts, namely if you can and want to treat the browser as a rendering engine for state snapshots. If you break with that assumption, you want something else, or you'll be slowly creeping into an ad-hoc, complicated mess, where there is no clear abstraction boundary for the UI. You just end up smearing it all over your code.

There are some fundamental reasons for this.

A technical one is that HTML isn't just data representation. It also dominates the shape of your UI tree. Do we really want to complect these things? The separation between HTML, CSS and JS is extremely leaky and blurry. The more you try to pull them apart, the more painful it gets. It's also the ultimate de-normalization of your data. Meaning it's going to be a huge PITA to coordinate if its not done in one coherent place.

Another issue is that you are breaking a separation of concerns and encapsulation. Does the server really have to know how I just toggled a menu, rearranged some widgets with drag-n-drop or switched a stylesheet? Trivially no. The server might care about some of that happening after the fact, but almost never about the details of how.

But this gets even more pronounced when you implement features touching on security, consistency and reliability. With a clearer UI and server separation you have two distinct mental models or modes. On the front-end you only care about the user experience and optimize for that: Immediate feedback, guiding messages, visualization and transitions. You can treat the user as your best friend and fulfill all of their wishes. But on the server you treat them as an incompetent stranger and/or as and adversary. Because, you know, its the Web! With this separation you enable focus and avoid mental taxation mixing things up. It's ultimately a simplification in the pure sense of the word.

With all that said, I don't doubt that many find this paradigm useful, especially because of what you said in your last sentence. And I'm sure that in many cases you can work around the problems I mentioned, or even model them well if you don't break with the assumption I mentioned at the start. But if you do anything interesting _in_ the browser you'll likely be forced to patch over the fact that you are now smearing your front-end logic all over places.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: