abhchand

I've been working on SimpleeFood, a simple self hosted recipe app

https://github.com/abhchand/simplee-food

I’m working on SimpleeFood, a simple self hosted recipe app.

https://github.com/abhchand/simplee-food

I found most of the offerings out there to be too bloated. Recipes are a simple thing - you want to store them, search them, and view them easily.

It has a full screen viewing mode for easy cooking with your tablet or phone.

Yes I would say it is used correctly here, with the definition you mentioned. And your english is good for not being an english speaker!

This feels like adding syntactic sugar in some sense. That is, a layer of convenience to accomplish something that can already be accomplished today.

It also breaks the following:

* It's better to be explicit than infer * Keep specifications simple

DDG works great for ~90% of my queries. I do fall back on Google every now and then, but DDG honestly delivers results that are just fine.

A lot of webdev content (tutorials, blog posts, documentation, etc...) relies on being able to display multiple files and code snippets at once.

I've always felt these files take up too much space on the page, and that there's a more compact and intuitive way to display them.

I created `VanillaTreeViewer` as a minimalist file browser for compactly displaying several files at once. It's modeled after the look and feel of an IDE, so it provides a clean way for viewers to see multiple files and their directory structure at once.

Demo: https://abhchand.me/vanilla-tree-viewer/

Author here.

A few months ago I saw an article from RefactoringUI posted to HN about building your own color palette. https://news.ycombinator.com/item?id=25180180

The concept seemed so simple that I can't believe I hadn't heard of it before as a developer.

It motivated me to create a color picker based on that methodology that lets you build an entire color palette.

It's written in ReactJS + Jest, and the source can be found here: https://github.com/abhchand/niram-color-picker/

This practice exists in traditional eastern Yoga - breathing out of one nostril and in with the other. A similar explanation is given about it having a calming and energetic effect.

I know that doesn't provide the evidence you were looking for, but hopefully it provides some context on where this might have originated from.

Is there a framework out there that faces as much consistent scrutiny as Rails?

It seems odd that for a decade the web dev community has singled out this framework. It's always relevant to suggest updates and things to be fix - any framework has those. But the continuing conversation of "is Ruby on Rails good enough" (which seems to be the underlying driver for conversation) is still present after hundreds of companies have built solid products with it.

I like this idea.

In response to it just creating more echo chambers:

- it can't be worse than now - At minimum, it's an echo chamber of your own creation instead of being manipulated by FB. There's value in that, ethically. - Giving people choice at scale means it will at least improve the situation for some people.

It seems that WhatsApp has some oddity in how it handles captions on media items.

I forward messages between various groups, but when you forward a media item like an image, it doesn't forward the caption with it. This is incredibly frustrating - sometimes you don't realize you've forwarded a photo of something that has no context, and my recipients have been often clueless until I have to clarify.

how'd you take this photo? :)

Just learning more in depth about websockets. It's been around for a while but i've honestly never had the chance to play around with them.

Thinking of putting together a small app as an excuse to play around with websockets

Sadly required, but seems very honest and relatable. Would probably share with any woman in tech.

As a secondary point, I find several of these applicable to me as a guy too, although that's not the main point of this.

I also really like this formatting and list style - heading and brief to-the-point description.

Great concept. I would've prefered an option to switch the days of the week and dates of the month. That way the numbers loop and the day of the week is fixed as a row/column header. That's more similar to how we read usual wall calendars.

While Facebook will select the first 11 members of the board, the eleven will choose the remaining board members, with terms lasting three years.

Call me skeptical but that's not enough to distance yourself and set up a "fair" court. Facebook still has lots of influence and I doubt they'll recommend something that would truly hurt Facebook's bottom line.

well that's scary

This was my same thought. Really impressive as an exercise to develop this yourself, but this is core functionality of a lot of ORMS. Rails' ActiveRecord is kind of the shining example of this, with it's `schema.rb` versioning file

For reasons like and to avoid confusion I always name my environment file something specific like `.env.development` or `.env.dockercompose`

Any system that reads `.env` files usually allows some way to specify the exact file to be read.

It takes a lot to even replicate some of the functionality of Google search. Huge credit to the DDG team for providing the second-best search results out there along with a much cleaner and privacy focused UI.

I do occasionally go back to Google but that's for less than <10% of my queries and when I do it's after a few attempts at finding something on DDG.

Definitely recommend to anyone for use.

Hate this is a problem that needs to be solved.

Love that Twilio is trying to solve it with a cool, seemingly useful approach.

Hate that Twilio will probably use something proprietary for this that locks people into their ecosystem even more.

The other thing that is ignored is that for seventy years Kashmir has gotten the biggest share of the central government's outlays for states and they have nothing to show for

This is a poor view of how areas should be funded. Governments are responsible for common welfare of a people, not to be run as a business that expects kickbacks and profit or returns on investment.

Clear and simple guide. I struggled to implement SAML login for so long on a project because every guide is just a long enterprise wordy document or doesn't correctly defines terms and concepts.

Some reasons, playing devil's advocate:

1. While today's incident was unfortunate, Slack has been historically reliable.

2. There's a team of real people that works very hard to keep it that way. Using dismissive language just dumps all over their hard work.

3. It's easy to be dismissive but once you move away from Slack you'll realize how much an app that size gives you. IN other words the "sucks less" statement has shades of ignorance, and of course subjectivity.

4. Why be rude at all? Even if you don't buy into any of the above, is it that hard to be nice in making a point?

a bit of both?

Honestly, it feels like the web is so bloated sometimes. Are the fundamentals really that difficult? We have raw CSS and at most we can have a layer above it that generates manage-able CSS (e.g. SASS). Why introduce all this un-needed complexity?

The curl project continues to be a fantastically run project

- It has stayed focused on one problem area, and only providing enough functionality to solve that set of problems (fancy way of saying it hasn't bloated)

- It is well documented and new features are well communicated

- When it does add features, the maintainers are features slowly and focus on quality. This is also in part because curl is such a fundamental tool that a lot of other software that relies on it would break if it wasn't rock solid

Just check out the length of the PR for this "simple" change of making the functionality parallel: https://github.com/curl/curl/commit/b88940850002a3f1c25bc648...

First half of the article that redesigns the navigation is actually pretty good. It got me hooked and i find it valuable.

When they started touching the content, I got a lot more hesitant.

1. I can't articulate why, but honestly it's extremely useful to see the last commit message on each file. It gives me a sense of which files have changed and if my changes are still the latest ones. It's not foolproof, but it doesn't have to be. It's more psychological but still necessary in a comforting sense.

2. Second, the reason github was successful is because unlike other repository UI's, it showed the code front and center. Nobody wants to look at a commit log, which is the approach that most other repositories used to take. Github cleverly realized that people want to jump right into the code or better yet understand the code, so they showed the file browser and a README. That pattern seems so obvious to us now but it wasn't always. It's kind of laughable that the article focused so much on design but failed to get the core of that idea.

Err nope.

This is kind of a flippant dismissal based on the multiple findings backed up by numbers. Yours may be an anecdotal story (and not my place to comment on) but there's no evidence that welfare dependence causes crime. It seems to be more of a political talking point. There may very well be a correlation, but it doesn't imply causation.

Someone on HN previously mentioned that every project they've started with Sinatra, they've regretted down the road that they didn't use Rails.

I think the complaints about Sinatra are vaild, in that it needs to limit how params are accessed, better startup documentation, etc... But ultimately Sinatra is for building super simple crud apps. I don't even use it for anything that accesses something more than a SQLlite DB. I often use it for serving up basic front end assets and running single page applications that have some small server side component to them.

It's footprint is lighter than rails, but so is it's intended functionality.