paffdragon

Wouldn't we still need a "Line Separator" character so we can include line breaks in fields and records for formatting purposes?

Do you have any examples what tends to break? We used pyenv/rbenv/sdkman etc. individually, then moved to asdf and now arrived at mise. Not using yet for CI just developer stuff and so far didn't have issues. But this is quite recent for us, so didn't have to deal with upgrade issues yet.

Making money from tickets is supporting the wrong behavior of trying to find excuses to ticket you for anything to get extra money - this is often leading to cops looking for cheap ways to get the extra cash where they can get it easily, instead of doing more important work where their chance to ticket you is lower even if more important for safety.

Isn't it too dystopian to have cars follow you around and report you to authorities? I can easily imagine some bad scenarios.

some providers accept crypto or even cash in an envelope

When I read the title I remembered how people in the 90s at my place built their lawn mowers. It was a new thing. My father welded the frame from scrap metal with the motor from a washing machine and some tiny wheels from an old baby stroller lol. It was kind of open source, many people copied or he helped build one. Haha, served us surprisingly well for a time :)

I use it in docker on a NAS - VictoriaMetrics, VictoriaLogs, Grafana - low resource usage, fast, so far zero issues.

I finished it anyway:

Your Programming Philosophy

You value clarity and directness in code. You prefer explicit, step-by-step solutions that are easy to understand and debug, even if they require more lines of code. Abstract ↔ Concrete: 0 Neutral Human ↔ Computer Friendly: +6 Human-Friendly

The compass is almost in the middle, just a little up from center towards human friendly. That's fine, since most code you write is for other humans to read, the compiler is writing for the machine, only in critical perf sensitive paths you write for computer-first... The rest was mostly neutral, because what I wrote in the parent, it depends on the situation and it can go either way depending on the project.

This isn't a good quiz. An example question (and there are many similar ones):

> When refactoring code, I prioritize:

> - Reducing complexity and coupling

> - Improving readability and maintainability

> - Optimizing performance and resource usage

> - Extracting reusable abstractions

Each refactoring has some goal, some driver behind it. It could be slow performance, unmaintenable mess, high coupling, too much duplication etc... Choosing a single answers makes no sense from a programming point of view. And this is the case most questions I have seen so far on the site.

EDIT: After finishing and seeing, I think I understand it a little better why was it structured like this. If you are open to do things differently, your answers probably won't weigh in any one direction in aggregate. But if you have certain biases, you might be leaning towards choosing similar answers that shows up in the end.

It's not that it is not possible, but whether it's a good idea.

The usual problem is that some team exposes one of their internal tables and they don't have control over what type of queries are run against it that could impact their service when the access patterns differ. Or when the external team is asking for extra fields that do not make sense for the owning team's model. Or adding some externally sourced information. Or the team moving from PostgreSQL to S3 or DynamoDB. And this is not an exhaustive list. An API layer is more flexible and can remain stable over a longer time than exposing internal implementation depending on a particular technology implemented in a particular way at the time they agreed on sharing.

This is, of course, not a concern inside the same team or very closely working teams. They can handle the necessary coordination. So, there are always exceptions and simple use cases where DB access works just fine. Especially, if you don't already have an API, which could be a bigger investment to set up for something simple if it's not even known yet the idea will work etc.

It's definitely worse for external customers, of course. But it's still not that easy even for internal customers. The main problem is that usually the tables exposed are not meant to be public interfaces, so the team takes on an external dependency to their internal schema. And that other team could have completely different goals and priorities, speed and size, management and end users with different requirements. At some point the other team might start to ask the first team for adding some innocent looking fields to their internal table for them. Also first team might need to make changes to support their own service that might not be compatible with the other team. The other team making queries that are not in control of the team owning the DB, which could impact performance. If possible, it is better to agree on an API and avoid depending on internal implementations directly even for internal customers. There are always some exceptions, e.g. very close or subteams under same management and same customers could be fine. Or if the table in question was explicitly designed as a public interface, it is rare, but possible.

That moves your API layer to the client library you need to distribute and build for your customers in programming languages they support. There are some cases where a thick client makes sense, but usually easier to do it server side and let customers consume the API from their env, it is easier to patch the server than to ship library updates to all users.

The team boundary is very important. You can get away with shared DB for a long time if the same team handles all services that access it and have absolute tight control over them. If there are different teams in picture, however, the tight coupling is a source of problems and a bottleneck, beyond prototyping / idea validation, etc.

> the interface being consumed is the database, which you do not need to design or implement

You absolutely should design and implement it, exactly because it is now your interface. In fact, it will add more constraints to your design, because now you have different consumers and potentially writers all competing for the same resource with potentially different access patterns. Plus the maintenance overhead that migrations of such shared tables come with. And eventually you might have data in this table that are only needed for some of the services, so you now need to implement views and access controls at the DB level.

Ideally, if you have a chance to implement it, an API is cleaner and more flexible. The problem in most cases is simply business pushing for faster features which often leads to quick hacks including just giving direct access to some DB table from another service, because the alternative would take more time, and we don't have time, we want features, now.

But I agree with your thoughts in the last paragraph. It happens very often that people don't want to undertake the effort of a whole new design or redesign to match the evolving requirements and just patch it by adding a new table to an existing DB, then another,...

You mean these? https://github.com/trvon/yams/tree/main/include/yams

Yes, and would have been great to discuss that in a civil way.

Samsung says you need to have the devices on the same Samsung account, same WiFi with Bluetooth enabled in https://www.samsung.com/us/support/answer/ANS10003445/. But I couldn't find more details on how the actual communication happens and if anything leaves the local network. The Samsung article does not go into details how this works, it does not even say explicitly that it uses the local network only. I tried to search for it, but Googling failed me on this.

But I was able to disable that sharing feature, so that isn't my main complaint, it's their clipboard data collection - [1], [2], [3]

[1]: https://cybersecuritynews.com/samsung-one-ui-security-flaw/

[2]: https://www.tomsguide.com/computing/online-security/samsung-...

[3]: https://windowsforum.com/threads/samsung-clipboard-security-...

I don't know why you make up such stories for yourself. It's completely pointless and has zero value.

Let me share you something, maybe it helps to update your perspective.

We reject people not because they help themselves with AI, everyone on the team uses AI in some form. Candidates are mostly rejected, because they don't understand what they write and can't explain what they just dumped into the editor from their AI assistant. We don't need colleagues who don't know what they ship and can't reason about code and won't be able to maintain it and troubleshoot issues. I can get the same level from an AI assistant without hiring. It's not old vs. young, we have plenty of young people on the team, it's about our time and efforts spent on people trying to fake their skills with AI help and then eventually fail and we wasted our time. This is the annoying part, the waste, because AI makes it easier to fake the process longer for people without the required skills.

I went through something similar, Todoist, Wunderlist, etc. We used these also together with my wife for a while. But sooner or later we reverted to paper for ad-hoc lists and some docs, spreadsheet software (Google Drive, Synology Drive, MS OneDrive, LibreOffice - whichever was easier) for more long term or longer content, and have a small board on the fridge serving as the shopping list.

Personally, I have my own "notes" script, a combination of shell and vim script for general note taking. I can organize things in folders, have a todo file, tags and indexing of tags (a folder of tags, each tag is a folder that contains symlinks to the related notes). If I just run it without a file, it opens a new daily note with the current date. I use that also for work tracking and TODO, I create a new note each day, add my tasks, tag it with the sprint. I can freely grep anything, I can quickly create a sprint summary from the tagged files, etc. I can back up or sync with git or any other software that works with plain text files and folders.

This is very simple and hacky, but haven't had to touch for years and it works for me - only me, only on my laptop, I don't need it on mobile. To carry around a list I use post its. For other purpose I have a physical notebook.

It is definitely not for everyone and that's fine. There is no one fits all. This is what I found working for me, minimal overhead, I can change/fix anything anytime, works with standard command line tools.

> You're just an impatient paranoid, easily jumping to conclusions. You should be ashamed for spreading false information.

Thank you for your kind words, please look at the HN comment guidelines when you have a chance. Your point would have been an excellent correction if shared thoughtfully, but it's all negated by the name calling and personal attacks.

Somewhat related, I was quite surprised when I discovered that my Samsung phone was sharing ALL my clipboard with all my other Samsung devices, including passwords copied into the clipboard, and even preserving the history. I can't remember if the sharing was enabled by default or I opted in by accident. I assume it also goes through their servers to reach my other devices. I could disable the sharing, but still can't turn off the clipboard history, even switching to a different keyboard, the Samsung keyboard still captures the clipboard and saves the history, when I switch the keyboard to Samsung everything is there... I guess my next phone won't be Samsung.

We have also seen this about a year ago when hiring. But only a couple of them made it to the live interview and then it was evident. Most of them were quickly filtered out based on the coding submissions. We are soon about to hire again, with the uptick in LLM usage and newer more up to date models, I'm not looking forward too much having to deal with all of this.

Reminds me of the Škoda Fabia with 1M kms I read about some time ago https://www.skoda-storyboard.com/en/models/million-kilometre...

I once set out to share dotfiles as I set up a new workstation, but later removed the public repo. I realized I am often careless with that stuff, since it only lives on my machine and I am not managing them as public content, nor I want that extra overhead.

Is that specific to using Rails or it is good with plain Ruby as well?

It's perfectly fine. The important part is that you can explain during the interview what you did to achieve that impact and demonstrate the skills. A lot of BS ends there. I never threw out a CV because it contained too many numbers or it was too precise. Quite the opposite. I flag CVs that are too vague and use big words without facts often repeatedly but do not provide much information.

Funny, but that was my impression of UK when I first visited (like 20 years ago). Cones, everywhere cones. As opposed to what I was used to in Eastern Europe where people just jumped off a car with shovels in the middle of the crossroads to fill a hole while drivers tried to navigate around them.

Yep. We once had left a socks proxy unprotected on a public IP, no cert, just a random IP and a fixed port. At one day the service stopped working. When looking into it, the network was overloaded with random IPs from all over the world surfing on the free proxy.

My use case is being productive at my work. If it was not designed for that, then not sure what is it for. It comes up fairly often in team chats, it's a resource hog with ridiculously high memory usage, poor browser utility, syntax highlighting selecting random languages,... I'm happy that it fits your desktop app use case, but there are also other people that see this as a limitation and sign of poor design. Web development is complex, but acknowledging that there are poor web apps and better web apps is part of that too. And from my experience and in my opinion (also shared in my team), Linear is an example of the bloated web app that is making the web worse for us, which is why I brought it up above.

EDIT: the parent I was replying to talked about the issue of opening links in new tabs and your answer - don't do it, use it like a desktop app - is basically the problem we are having with some of these web apps.

This is so annoying when SPAs break browser functionality like open link in new tab. Even if it works often it has to reload a bunch of JS again, which makes things veeery slow. This is why I really don't like Linear, I often open issues in separate tabs, which is every time a pain, browser freezes for seconds just to open a link in a tab...

I use a user agent switcher extension to tell Google I am browsing with Lynx to remove some of the annoyances.