unleashit

Hey, the bottom line is the project looks promising and I'm sure it's a lot of hard work. That said, because time is limited, for now I'll have to pass on spinning it up for the reasons mentioned. I took a look at the shell script, and it just seems like a helpful wrapper (with cleanup) over a manual install. I didn't mean to say it's about the amount of containers. All of those services take up a lot of resources, especially compared to the alternatives.

For example, Openwebui can be run with just a sqlite database and a backend. Why is nginx needed, or Minio on a single machine with a nice local file system? But I also understand it takes more work to support multiple service configurations so please accept the criticism as constructive (and it's more a general observation of what I've noticed over the past few years).

Side question: It looks interesting but what's with the trend of open source projects providing such bloated installs? The recommended getting started with docker (which first recommends cloning a 350mb repo) seems to assume you need to scale to 100s+ users. At a glance, in their default docker compose I counted no less than 12 containers including nginx, redis and minio. I can't imagine any of these are necessary to run an app on a single localhost machine.

I understand they're trying to attract enterprisy customers, but even some of those are probably going to want to try it out first. Would be nice to have an easy minimal install option that doesn't require a deep dive into the project to figure out.

Seeking ~32 hr/week position

Location: Portland, OR

Remote: Yes, and/or in-house. Experienced with both.

Willing to relocate: maybe (SF Bay Area or Seattle only)

Technologies: Typescript, Javascript, React, Redux, Next.js, Node.js, Express, HTML, CSS, REST, GraphQL, Postgres, Mysql, Linux, Nginx, Docker, Serverless, AWS, Vercel, Ansible, Terraform and more. Experienced with LLMs and AI coding tools.

Resume and Portfolio: https://jasongallagher.org

Contact: please use contact form on my website

Github: https://github.com/unleashit

I'm a seasoned Front End Engineer (Full Stack Typescript/Javascript) with 20 years of professional experience in a variety of industries. My specialty is front end and React although I'm also skilled in back end web technologies. Currently I'm seeking a long-term 3/4 time position.

The evidence is tell me how many tech companies, especially startups, have a large ratio of over 40s? If age discrimination were better enforced, the OP might have a very different (and more fair) market to try your experiment. Until that happens, the OPs observation that they are under compensated vs. other workers of a similar skill set would be where I'd put my money.

Sounds like you have an inordinate amount of faith in the market to decide what's fair.

Thanks. Need to try MSW, but right now it's not clear to me how it can be used more than a fake HTTP endpoint. With Storybook, I can create links with any set of props I want for each component (or change with the controls). A lot of state doesn't rely on a back end (client side history or user prefs stored in local state, etc.).

Thanks for the explanation, but I still don't understand how MSW and Storybook are comparable. As you said, MSW can be used to isolate a "backend". But Storybook really mainly to isolate the "frontend" parts. I see the point of both. On that note, while pretty happy with my current mocking solutions I've been meaning to take a closer look at MSW!

How does SB require a certain component structure? I didn't have to touch mine. They have a "sub component" feature for documenting nested components that work together, although I didn't even use it. Just used either decorators or render functions in my stories where needed (which did require a little wiring up to update the args).

I don't use Tailwind (yuck, sorry!), but how is choice of styling a factor?

The auto docs have some weird glitches and did force me to adjust my TS types a bit is my complaint (and react-docgen-typescript wasn't working for me at all).

I agree that SB is probably not worth the effort for everyone though.

Haven't used MSW, but don't people use it for mocking APIs? Isn't that apples and oranges? If your stories need data, you can always still use MSW. But otherwise when it comes to testing (in the app vs. Stories) I'd agree. Not exactly testing, but the play feature beats E2E if you want to show a smooth demo for clients/fellow devs.

As far as live reload, you're right but only once you've achieved the state. If you're firing up storybook or moving between components, you can already have any state ready to go (or quickly set with the controls). If you're in the actual app and don't have something like Redux Dev Tools, you have to manually go through the steps.... which can be a pain.

That said, so far I'm only using Storybook for the "component library" use case. And for that it's a big improvement from the previous DIY app I had.

Just finishing up a Storybook based on the v8 beta and was pleasantly surprised how far it's come along since I last tried it a few years ago. The auto docs (with the help of react-docgen) while still a bit rough on the edges and buggy in the new release is amazing. I wish the documentation was a bit better in some areas (the examples are usually repeated simple use cases from their demo content like a button) but I was able to achieve most of what I needed and then some.

For those wondering what the use case is, you must not have tried it. It does take work to set up (with each version that's less), but it can be very nice to test in isolation esp in cases where a component is under a login, the 4th page of a 10 page form, etc. Also obviously if you're working on a component library that ships without an app, Storybook can be your development and/or demo app.

This is such an interesting attitude. I hope I don't inherit any of your projects. I have the opposite take... that the world needs him more than ever. Tailwind is the pump and dump of web development. I can definitely see the allure when it comes to hammering up the fastest possible prototypes with minimal knowledge required, but in reality it's 1 step forward and 10 steps back.

It's legacy is going to be more of bummer than a lot of folks realize I'm afraid. What are you going to do when the Product Manager comes in with the new design comps after you've hard coded all that html with the disparate output of ChatGPT and/or various pasted in snippets from libraries like Shadcn?

I suppose it's not too bad for trying to see where the sun don't shine.

Exactly and IMO we would all be better served if F/T employees were treated more as "temp to hire". Contractors would still be contractors in terms of taxes, benefits, expectation of where/how services are rendered, etc.

Just wondering, do you think it would have helped your situation if it were the cultural norm to "try before you buy" for both parties? Obviously it takes time to get up to speed and productivity, but it seems better and more productive for you not to have an unhappy employee in the long-term.

I get that any kind of turnover is tough to manage especially if you're a small team. But if we all (employers, employees, customers/clients/users) were to became a little more prepared for a certain amount (within a short period of time after hiring), it would simply become the expectation. As it stands, companies are now afraid to hire and employees are afraid to seek due to the ever more byzantine hiring process.

It may not exactly seem intuitive, but I believe if either firing or quitting (at least within some type of trial period) became a little less stigmatized on both sides, we would all live in less fear and end up much more productive in the longer term.

Lol. Judging from the last rocket I think there could be some nose bleeds for cheap. I humbly ask though instead of mars, go colonize somewhere in a galaxy far far away. Otherwise, you'd be much too close for comfort for us Earthlings.

If you're so against hearing any kind of rationalization or nuance about the drawbacks of unchecked population growth, please buy a ticket from Elon and turn some other planet into your Coruscant. Because some of us like this one, and we humans are destroying it with that kind of selfish thinking.

It's as if some people can't see that there might be middle ground between say an evil Eugenics master plan and a little bit better family planning for a few generations.

As a designer-turned-developer, I find this topic and the comments amusing. I don't think there's much question that the agency in question treated the client terribly, and should have been fired post haste and early.

That said, you couldn't pay me enough to get involved with design again in any way shape or form. The reason, as reflected by the comments and experience, is greatly increased customer expectations of the design process, number of expected mockups/choices, iterations, content changes, scope creep, etc. Even for small projects like the OPs, it's has ballooned to such an extent that many times it's practically impossible to know if something is going to take weeks or even years.

10 years ago when I last did design, if this author approached me I'm confident that I could have delivered a significantly better end result in far less time and at a cost similar to the original estimate. However, I would have be up front at the start (and in the contract) about maximum iterations and time spent before triggering the hourly rate. This most of the time anyway, worked pretty well to set the client's expectation to what I needed to match their estimate. I do understand that this wouldn't be palatable to most businesses anymore because it means having to be more trusting and flexible about the end result. Yet in almost all cases, I was able to please the companies I worked with and do it mostly on time/budget. Indeed, they sometimes had to compromise a bit but the end result as measured by revenue and traffic was almost never disappointing to them.

I'm a big believer of listening carefully and delivering not what "I" want, but what my customer wants. That said, I also believe business should be open to the advice of design (and other) professionals, because that is what they spend all their time doing. If you're fighting stuff like color/font/design choices with your designer to the extent that you have to go through a million changes, you've either picked the wrong designer or you might also consider the possibility that you might not be effectively communicating your opinions and/or that they might not make sense.

The point I was trying to make was just because Tailwind doesn't happen to be expressive enough to get you into that particular kind of mess isn't a reason to use it. True, its fair to say you can write bad CSS or SASS, but that's the same for all programming languages. If your main goal is something foot gun free and safe for the inexperienced, might as well go all the way and recommend low/no code or even Squarespace.

I think the reason a lot of ppl think they need tailwind, is because a) they aren't familiar enough with more current CSS techniques like CSS modules and linting which can limit stuff like nested descendant selectors and/or b) they're tricked into thinking they won't have to learn as much about CSS (a dangerous fallacy unless you're sticking to the most basic of prototypes!).

I don't think the example compares. In languages like JS, double, triple or even further nested ternaries are possible. But terser isn't always better because human readability is important. I can easily understood your SASS example because I know SASS, but I'd never write it like that. If I really wanted to add a decedent selector from a body class to .class1, I'd start a new nest on the body tag.

The problem with Tailwind is there's nothing you can do to avoid the much more difficult to scan and understand syntax described above. I personally don't understand why people are drinking this koolaide. I really think this is a fad a lot of people are going to come to regret when they go back to maintain older projects based on it.

100th birthday celebration for Sarod master and Bay Area Treasure Ali Akbar Khansahib.

Sidenote: I'm very impressed that in 2022 the community chose to put some creative energy into a website. It feels so much more personalized than the typical page on a ticket/event service and/or Facebook.

Khaaaaaaan!

Originally in the intro to the second star trek movie: https://en.wikipedia.org/wiki/Kobayashi_Maru

Sorry, haven't even read the article but I just love how the nerds are still preserving the memories and lessons of Star Trek II: The Wrath of Khan.

I love how the new Reddit gets frequently used as a straw man in arguments of front end developers are bad, the state of front end is a mess, etc. If you care to look at the actual reasons that Reddit and so many modern websites really are terrible, you'll see that it comes from the top and in many cases is on purpose.

Reddit (and many others) don't want you to use their website. Especially on a mobile browser. They want you using their app where they have access to more of your data and generally keep you longer. And also where the initial payload of advertising and analytics cruft feels faster to you because you probably are more inclined to be patient with the mobile install/update lifecycle than you'd be with a browser. The GUI changes too were much more likely to come from product management than your lowly front end bootcamp graduate.

Waiting for a good UI library comparison that focuses on how the library works, how it's customized and how it performs. Instead, they usually focus on stuff like Github stars, which companies are using it, etc.

Those are important of course, but it seems like these posts seem to always be geared towards people who are basically creating stock prototype experiences. The first thing I want to know is how do I customize the components? Can I do it the way I'd like (i.e. SASS vs. CSS in JS vs. Tailwind, etc.)? Can I surgically (and easily) only include only the CSS and Javascript that I need... and lastly what are my options and tradeoffs with the build process. It's pretty easy with Ant Design for example to wind up with a huge bundle even if you use a fraction of the library.

Wondering why you think this is better. Not sure the trade off of a messy dockerfile and/or adding a bunch of layers (possibly bloating the image size) is worth the trade off if the concern is just about forgetting to update the dockerignore. The same could be said about gitignore.

Yeah that could be it. I use the gamepad or sometimes an air mouse. Both work fine. My only gripe is Nvidia doesn't let you put side loaded apps on the homescreen.

It works well for me on Android TV with Nvidia Shield. At one point I noticed after a Newpipe upgrade I couldn't get the cursor to go down to the list of videos. So I downgraded for a couple of weeks. Then when the next version came out I tried it and it was fine again.

One weird thing I noticed was that I used to be able to get a mouse style cursor with the right stick, but that stopped working at some point. Not sure if the change was NewPipe or OS level, but it's still manageable.

If you have USB ports you can always try other types of inputs. Aside from plain keyboard/mouse, there are a bunch of interesting options these days.

I've done contracting work off and on for 20 years. The day some sort of forced surveillance or micromanagement of pee breaks becomes impossible to avoid, will be before the day I stop doing contract work.

Trust works both ways. As a contractor, I have to go "way" out on a limb to trust you. Trust you to pay me, trust you to pay on time (I'm not a large vendor with multiple accounts to fall back on for cash flow), trust you to make decisions and supply content/assets on schedule, trust that you won't end up crazy and hard to work with, etc., etc.

If you can't trust me, why should I trust you?

That said, it's very easy. If the work gets done and as expected, you did well.

The problem I think is more that you're looking for full stack. Try a front end developer. These have deeper Javascript, html, css and web/browser specific knowledge then a lot of so called full stack people have. The former are the fundamental skills you're looking for. React itself I would consider less important as long as they have experience in one framework or another, or unless you have very simple needs and no time for a even a short ramping up period.

If you follow this advice, you will tap into a HUGE resource of developers who have ridden the tide of front end for a long time but haven't crossed over into full stack because it was never expected until recent times. Of course it would be ideal to find one person who can do it all. But from my experience it is orders of magnitude harder to find a good traditional software engineer who can also rock the front end. Depending on your process and desire for good UI/UX this will especially hold true...

What's your definition of an "off the shelf" front end dev? And if you want to pigeon hole just front end developers (I meant industry wide), what is it you think can possibly be so special about the UIs of over half of everything that someone with many years of experience (possibly from a variety of industries) can't come in and quickly be effective? Isn't there value of someone who can handle new challenges over someone siloed into a single area?

I would say your comment come across as elitist and the evidence I have is also my personal experience. I've done it many times and rarely has anyone not been happy with the results thus far. Obviously there are industry specific areas of expertise that can be deep, and I can see where there are times you might have to hold out for the right candidate. But I think the figures you give reflect stem much more from personal bias than reality. Sadly, a lot of HR agrees with you which is why it's it's become needlessly hard to hire/find a job these days.

Indefinitely posting while hiring only once every six months is actually the poster child of the problem. If it really takes six months to find someone to fit the role, you might want to take a look at your hiring process because as you must be rejecting (or ignoring the applications) a lot of great, qualified people.

IMHO if someone did take the time to publish the metrics of companies who perpetually post the same positions, it would be a fair counter balance.