I’ve been wanting to try LM Studio but I can’t figure out how to use it over local network. My desktop in the living room has the beefy GPU, but I want to use LM Studio from my laptop in bed.
Use an openai compatible API client on your laptop, and LM Studio on your server, and point the client to your server. LM Server can serve an LLM on a desired port using the openai style chat completion API. You can also install openwebui on your server and connect to it via a web browser, and configure it to use the LM Studio connection for its LLM.
It might mitigate some of your issues by using themes that are anthracite / charcoal / deep gray instead of pure OLED black. Due to the way screen technology and bad eyes work you often get slight halo-ing or double vision with white text on pure blacks.
Also definitely stay away from Solarized. The contrasts on Solarized get muddled really quickly if you run your screen at low backlight intensity and especially if you use a night light blue filter / orange overlay.
Dark editor themes has always been one of the most laughable of orthodoxies in tech. Contrast is key for reducing eye strain, especially for extended sessions. And Solarized doesn’t have nearly enough.
(I suspect a decent chunk of Solarized’s popularity came from the fact it was popular, rather than the “science”-based facade it marketed itself as.)
Oh man, I always thought it was some kind of joke theme or something like holiday themes that people only put on for a lark. I didn't realize people actually used it as a daily driver theme. How is that even possible? Even in my 20s I thought it was terrible.
> On top of that, once you finally get a feature merged and deployed, it can often happen that there’s a bug causing users to have a poor experience. Since your new feature lives directly in the code, deactivating it requires rolling back the code you merged, building it, waiting for the tests to run, and redeploying the application
Why aren’t you using feature flags to gate new behavior/functionality?
This is literally what the article advocates.
It pushes things to the extreme where every code you write would be on the main branch and behind a feature flag
Feature flags have nothing to do with trunk or git-flow or feature branches. Simply, taking the entire introduction and asking, why are you not using common tooling?
More as people who value simplicity and hackability.
Like if you use C# you obviously value structure and organization over many other things and aren't afraid of spending money, so deploying everything on your inhouse Kubernetes cluster makes perfect sense. If you use JavaScript you probably have some kind of compile step, and after deploying you need to somehow restart node anyways; Docker makes this easier and more reliable. But if you use PHP the relative advantage of Docker over rsync isn't nearly as big, but Docker adds a lot of incidental complexity.
And if you are small enough you probably want some kind of serverless hosting. With most languages that involves running a tool that creates a docker image and uploads it to that provider. PHP invented that a couple decades earlier and called it shared hosting. It's not as cool and has worse versioning, but functionally it fulfills the same purpose. It just happens to predate docker.
Visual Studio used to be basically mandatory for developing C# and costs $500 per year per developer or more (unless you are happy violating the license of the community edition). Paying for libraries is also completely normal in the C# ecosystem, it's easy to pay another couple thousand per developer for library licenses.
I think you tend to get good value for your money, developer salaries are expensive after all. But for any other language (maybe besides C/C++) this is much less common and the paid products that do exist are much cheaper.
How does this relate to docker? Only really in combination with the other attributes. Rsyncing files into production isn't as traceable, organized, structured or auditable as many of the Docker-based solutions out there. Those solutions can get expensive at scale, but if you use C# you are used to that
Hence the "used to". Both became options 8 years ago and took a bit to mature. Before 2016 everyone had Visual Studio licenses and on top of that got JetBrain's VS extensions.
Your whole comment history with regards to PHP reads like someone frustrated that the tool they've chosen to shit on is exactly the opposite of what they think it is but they don't want to admit it.
You're requiring PHP 8.3 but not using some of the most powerful tools in 7+: strict types.
```
/* @var array<string, mixed> Variables stored in the context */
private $variables = [];
```
This should be typed as `array` (heck, I'd argue ArrayObject instead) and all your classes should have `declare(strict_types=1);` at the top.
Your `Dumbo\Helpers` classes are basically static mine traps that you are unable to mock in unit tests. Why does `BasicAuth` expose a single static method but then calls a bunch of other static methods? What ends up happening in any class that uses any of your `Dumbo\Helpers` classes will always run whatever code is defined in these helper classes.
I'm unsure where the bootstrapping process begins. What file does your webserver need to call to handle a new request? I am hoping it is within a root-level directory and not at the root level itself. In other words, `/public/index.php` vs `/index.php`. Your quickstart in README.MD makes it pretty clear that you expect the latter, which is highly unsafe. See any number of poorly configured webservers that stop processing PHP for any reason but now show your site's full contents to anyone passing by.
I would strongly argue against _any_ magic in your framework. Specifically, routes: they should be explicitly defined. I still work with a legacy Symfony 1 framework project and I can't tell you how much I detest magic routing. For a modern example see how Symfony 2+ requires explicit route definition. Heck, how it requires explicit everything because magic should be left to magicians.
Your framework seems like it can only handle `application/json` and `application/x-www-form-urlencoded` requests, but not `multipart/form-data`.
Take these as positive criticisms of your work. It's "fine". I wouldn't use it, I would actively recommend against using it, but I would actively recommend against using anything that's not Symfony (or Laravel if I were drunk). I do not think your project is at the "Show HN" level - it is still far too under-developed.
1) *magic*
2) Its ORM of choice uses ActiveRecord pattern which I find to be hideous. DataMapper is far superior
3) Its weird facade patterns is terrible
I can (and have!) gone in-depth into my misgivings with Laravel, but it is fine for most projects and teams. It has elevated the average codebase quality throughout the PHP community and introduced many engineers to what PHP can do. Its creator and community have been a large net-positive to PHP as a whole.
I still prefer Symfony:
1) explicit
2) DataMapper ORM by default
3) What I am used to
What do you think of Slim Framework as far as best practices for modern PHP in a micro framework (which is similar to OP's Dumbo)? Are there any other micro frameworks you recommend?
At the risk of being piled on by fans of Slim (see fans of Laravel), I don't use slim frameworks.
For large projects when you get down to it, slim frameworks are simply frameworks where you have to add in components yourself, vs shipping with sane defaults.
Symfony comes with Doctrine, Twig, etc, but you can choose not to use them or even include them.
With slim frameworks if they are built correctly they will have hooks to add these components but you have to choose them and import them and set them up.
I have not worked on a small project in years, and have not bothered looking at slim frameworks in as much time, so my knowledge might be out of date ... but a quick glance through Slim's documentation tells me I'm still fairly close.
I'll add on to this too, as someone who largely agrees!
I work for a company that has several mid-sized PHP projects. Some started life back with early PHP5 - eg 5.1.
The biggest reason I don't like slim frameworks is that they make every project unique.
Projects that start small rarely stay small, and if every project gets to pick it's own router, it's own method of doing CLI commands, it's own ORM, it's own messaging/queue stack, etc - then well intentioned decisions create a ton of variety in projects over time and it makes it very hard for people to jump from project to project. It also makes upgrades a mammoth task.
We tested Slim, Laravel & Symfony and settled on Symfony.
We found huge advantages in using a framework that can be installed piece-by-piece as you need it, but where the pieces are the same every time & consistently designed, and where the whole thing is designed to be upgraded in one go.
Going with Symfony has been a genuine productivity improvement for us - every project follows the same basic structure, we try to follow Symfony best practices, we try to minimise tons of external dependencies. It makes maintenance much much easier, and makes something like 'hey, we really should be processing this async in the background' an easy step - just install symfony/messenger, rather than evaluating different options, etc.
edit: we didn't go for Laravel because Eloquent really didn't compare well to Doctrine, and the amount of hard to debug 'magic' was much worse for us than Symfony.
Symfony has a huge lot of magic (text/non-typed config files, factory/abstract bloats, ...), and even dark magic (compilation passes, ...), but it's better than Laravel in many ways indeed.
A simpler framework with modern techniques would be great though.
We are in agreement about Laravel's ORM, but I disagree about the magic. Laravel's "magic" is just convention over configuration, and most things can be configured as well.
Makes sense. I agree on the ORM. I actively don't use Eloquent when I use Laravel. It's fine for simple actions but I find it can get in the way as the project grows more complex. Thanks for sharing.
Too much angst about non standards and preferences. Everyone codes the way they feel comfortable and decides what to implement because the more mumbojumbo pattern magic included the more complexity you introduce to your codebase. And the development time skyrockets.
Just because someone wrote a book about patterns, it doesn't mean it's the high standard and the holy bible by any means. These people are mostly control freaks, who like to exert control on people and think their excrement is akin to a lump of gold.
And then there are the preachers - like you - who disseminate the bullshit these pattern monkeys rant day and night.
Some of my first OSS work was also based on Vagrant (https://github.com/ezekg/tj). I eventually turned that into a commercial desktop app, built on top of that CLI project. Ultimately, the project didn't work out, but it was a big step in my open source and entrepreneurial journey.
Any suggestions?