I feel like the explicitly go out of their away to avoid building in custom instructions/increased prompt context to lower their costs so this is a bit of a work around.
HN user
keithnoizu
Former chief software architect of greatnonprofits.org, former microsoftie, current expat, eternal geek.
c/c++, embedded c, elixir/erlang. Backend & Software Architect.
https://www.linkedin.com/in/keithbrings/
Elixir https://github.com/noizu/ElixirScaffolding https://github.com/noizu/SimplePool https://github.com/noizu/KitchenSink https://github.com/noizu/RuleEngine https://github.com/noizu/MnesiaVersioning
Php https://github.com/noizu/fragmented-keys https://github.com/noizu/domain-objects https://github.com/noizu/php-conform
Java https://github.com/noizu/fragmented-keys-4java
copilot scans open files so I mention the file name in my prompt or reference the file explicitly using the reference file option in the chat window in the intellij copilot chat beta.
``` Follow the instructions for preparing responses from the COPILOT.md file in how you answer and format your answer to the following prompt.
<whatever my request was> ```
I came across a nice little solution in copilot X and copilot 365/pro for including and referencing custom instructions to add behavior/formatting support to copilot (e.g. edit mode, article writing mode, documentation writting mode etc.)
and I felt like a rebel just using vga x mode.
Which is fundamentally different from how our brain chains together thoughts when not actively engaging in meta thinking how? Especially once chain of thought etc. is applied.
You can tell GPT to output sentiment analysis and mind reading of user intent, what it believes the user's underlying goal is. It becomes less responsive if it finds the user to not be friendly or perceives them as trying to achieve a restricted outcome.
Yes, I have a similar solution.
Not my stuff but maybe in a few weeks as there's some additional concepts involved.
I was really blown away by how well erlang/chicago boss handled throughput when I first gave it a spin. A webpage I converted over handled multiple orders of magnitude more incoming requests before failing than the php version it replaced.
CB would get frustrating when wanting to extend certain functionality however, which phoenix isn't quite as bad about.
yep, prepriming the cache rather than passively allowing it be rebuilt by request/queries can also result in some nice improvements and depending on replication delay across database servers avoid some unexpected query results reaching the end user.
In the past I was the architect of a top 2000 alexa ranked social networking site, data synchronization delays were insane under certain load patterns high single low double digit second write propagation delays.
I'm talking back-end not in app data caching. I would also cache misses there as well but with less aggressive ttl.
Yes. I handle around a million requests per minute. I exponentially increase the cache period after subsequent misses to avoid an outage ddos the whole system.
This tends to be beneficial regardless of the root cause.
edit this is especially useful for handling search/query misses as a query with no results is going to scan any relevant indexes etc. until it is clear no match exists meaning a no results query may take up more cycles than a hit.
DNS is back, looks like systems are still coming online.
Yep, I always make it a point to cache cache-misses in my code.
I came here to move fast and break things, and i'm all out of move fast.
some poor engineer is sobbing over a split brain mnesia cluster right now praying to get the thing back up.
somewhere an engineer is begging a mnesia instance to come back online.
Atlassian has a reputation for poor engineering/backend practices. It's a great (to use) product though.
print some spoof news articles periodically and sue them when they duplicate your "parody content" like the yellow books used to do to prevent duplication of phone numbers.
True, but even if we were say 80% confident in each rebuttal being the true reason chained together the odds of those all being correct is pretty small. Although of course it could be due to alternative rebuttals being the correct ones.
At a certain point in time, not that we've reached it, it starts to look like the ptolemaic system, or luminiferous aether, where you keep tacking on exceptions or explanations to fit the data to your model instead of your model to the data.
Or when the spanish invaded the aztec empire.
right after I shamed them on twitter. I take responsibility despite it unlikely having any impact.
Still down for me. Must not be a "vast majority of users" bit of a premature "green" on that.
mercury was better but . . . really?
Imagine for example that you have per record caches. You can run a query to get ids with out joining to the table and then simply fill in any gaps in your cache with a follow up query.
It depends. Regardless there is limited CPU, and so any scenario in which a stored procedure uses more CPU than a simple query will cause you to hit that saturation point sooner.
I generally have layers of caching on top of the sql server so the majority of queries will be integer equivalency or range checks, if not get by primary key queries. So I am not generally operating in a scenario where a stored procedure would reduce record scans, etc.
I generally also don't run on transactions out side of limited scenarios, since throughput is usually more important to me than data consistency.
I'm of the same mind. The way in which new antibiotics are identified for example.
On high volume applications I would avoid it since it's usually easier to horizontally scale web servers than sql servers, and it makes cache strategies more difficult depending on how and what you're querying.
Meanwhile where I live there is a single active imported case, and contact tracing being done for every he came into contact with directly or indirectly. Thailand and Vietnam, Hong Kong, Korea etc. have also done a excellent job at controlling the virus and opening society back up. But all you hear about is Sweden and New Zealand.
I find i'm normally a little better at grasping how all of the components work together on large systems than others.