kellros

Consider that as of (always and) 2026 you are held accountable for whatever AI-slop* you produce. Will that change within 5 years? The mindset is shifting from doing the right thing, to instructing the AI to do the right thing. Even if you're not responsible for the instructing part (e.g. using AI export feature drafts, to use an AI software factory to refine and implement), you're still owning said implementation in the end because you're responsible for the refinement and review. You should know how to do the work and reason about it—but you're also responsible now for correcting AI—less work but more responsibility.

As someone building AI software factories for the greater part of a year, I can share some learnings: - Smart models like Claude Opus cannot be replaced with dumber models at a reasonable expenditure with similar cost by iterating multiple times. Mythos will be the same cost or more expensive. Don't think you can throw enough funding at qwen-next-coder to rival Opus at a similar price. - Mythos (like Opus) will change the way we work, but not in the way you think. The use case for Opus is narrowing in comparison to Sonnet - a lot of what Opus used to do, Sonnet can do for cheaper, and sometimes better too. Opus is great at exploring a problem space and filling in the gaps - but any agent harness will not leave such intelligence to fate—they'll do fine-tuning or add specific instructions and possibly guardrails. Lazy (but long-term optimal) solutions will leave more reasoning to smarter models and dictate less. - A lot of what we do (and should do) is a cost optimization problem. Categorizing what we do (exploration vs. reasoning) tends to be structural (like Haiku), logical (like Sonnet instruct/non-thinking), and reasoning-driven (like Opus/thinking). Sometimes the challenge is long context-based reasoning, e.g. when planning a vision breakdown encompassing 50+ features, Sonnet could* do it given 1M context, but it struggles to reason about long context problems (Opus long-term reasoning drops off less) e.g. first 5 features are accurate, but the further you go, the less accurate it becomes (near-sighted vision). - If Mythos has like a 10m context size long reasoning window, Mythos would become the go-to model for medium-term planning (3-6 months). Opus 1m doesn't cut it for 3m-6m horizon planning, not to mention long-term (1y+ with 100++ features). The industry is in need of a x10 compression/context size improvement to tackle bigger problems. One of the challenges right now is we (as humans) can't refine and reason about features fast enough to keep pace with what AI can deliver—until AI has the ability to perform longer-term reasoning, we can't trust it to plan things longer term. There's another problem with this long-term reasoning in that we (as humans) can't (easily) reason so far ahead, but AI could if it could keep the entire context in mind.

In short, unless Mythos is cheaper than Sonnet (which is 3-5x more expensive than what is out there today, e.g., GPT Mini, Minimax 2.7, GPT-OSS 120b), it's unlikely it would become the go-to model.

I'd add that a smarter reasoning model can only be better if you provide relevant context and reasoning constraints — otherwise, you can't expect it to behave better (in actual terms) compared to a slightly dumber model. When you start reasoning about the future in terms of AI, it's turtles all the way down (i.e. need AI to efficiently reason about the choices made by AI)

I'll tell you later :)

I've always been fond of Rethinkdb, but never actually used it. Perhaps if I came across pragmatic examples of how to do x with y, like you typically see with Redis, I could have convinced my team/s otherwise.

One of the aspects of Rethinkdb I admire most is the tooling. I find myself often trying out something new with React, Postgres, ASP.NET Core, Elm, Go, Kotlin or what not and biasing my experience getting started with preference to use.

I recond Rethink as Pied Piper in Silicon Valley; a great product ultimately being misunderstood. I'm relieved to hear Rethinkdb will live on under the Linux Foundation (and applaud them for doing so) and earnestly hope it re-establishes itself in a niche, such as that of Firebase/Parse, with partnerships and a legacy to rival that of Postgres one day.

Nice. Slightly disappointed that the file being edited in the demo wasn't called "nuts" (https://raw.githubusercontent.com/schollz/sdees/master/brand...)

I have a sinking feeling: https://github.com/cristicbz/rust-doom/blob/master/src/game/...

Looks to be the case based on the config. I'm suprised storage wasn't abstracted to accommodate redis or the like which is essential in a load balanced scenario.

The API doesn't seem quite idiomatic either, I'd expect to create a struct containing options and a function that closes over the http.Handler interface e.g. func(l *Limiter) Limit(next http.Handler) http.Handler or a function that takes options and a next http.Handler that creates a struct implementing http.Handler.

I suspect flex-time will be coming sooner than expected. flexbox is amazing!

Edit: The whole idea behind clustering is to run an application instance per thread/core for better performance and load balance requests between the application instances. This article seems absurd in its intention to force you to choose between multi-threaded synchronous application instances or a single application instance using callbacks.

We've been running a Koa.js API server using Cluster in production for over a year now with no hiccups (on a Windows machine).

I've been thinking about making the switch to iisnode, as it handles clustering, graceful shutdown and zero-downtime from within IIS (and does a couple of other things). It uses named pipes to proxy connections and also supports web sockets among other things.

With the nodeProcessCommandLine configuration setting, you can pass parameters to node (e.g. --harmony), use babel-node or io.js.

See: http://www.hanselman.com/blog/InstallingAndRunningNodejsAppl...

A blog post I wrote a while ago: https://shelakel.co.za/hosting-almost-any-application-on-iis...

There was a post on HN recently on correctly using promises. A must read for anyone getting started with promises: http://pouchdb.com/2015/05/18/we-have-a-problem-with-promise...

I guess it depends on how averse you are to risk and how long you can go without getting paid.

Never forget that a contract is meant to be negotiated - a contract's first draft typically contains a bunch of unreasonable or vague requests and wishes from the party that created the contract. Don't sign a contract until the vagueness has been clarified or defined.

It's up to you to negotiate the contract in your favor. To put it plain and simple; unless you negotiate a contract in your favor, you're going to have a bad time. Like the video said; if you have no contract, you're left with the sympathy card and that rarely works.

Another bit of advice: Keep track of all communications and have all word-of-mouth agreements put on paper (before you commit to anything, like signing the contract). I keep a projects folder per client containing communications, documents received etc.

Hourly billing only works when you keep a detailed log of what was done. It's definitely a lot easier to get paid for work if you provide a breakdown on what was decided and done. The descriptions should prove as motivations of why the work was necessary.

Good to know :)

Some words of advice:

- Watch this video: http://creativemornings.com/talks/mike-monteiro--2/1

- Have a contract that stipulates what will be delivered and when, when payment is due etc. See this: http://www.docracy.com/topic/1e6bi5l90z/open-source-legal-do...

- Ask a hefty penalty amount for signing non-disclosure agreements (NDA's) - this is crucial for short term contract work

- Charge more. Figure out your hourly rate and average hours per day and extrapolate that out to a weekly rate. I reckon a fair amount is $50 an hour, while still staying very competitive with other software shops. See: http://internationalfreelancersacademy.com/why-you-should-ch...

- Be honest in what you can and can't do. Advise your client to contract out such work, whether it's designing the look and feel, designing logos or write content. Figure out or develop an advantage over other service offerings. Specialization is of key importance in consulting/freelancing work.

- Beware of overly stingy or difficult clients - it's sometimes necessary to fire them!

It must be IE gathering its numbers to face off against Spartan in the IEpocalypse.

Another theory is that corporates/governments are switching over from XP to Windows 7 (with Internet Explorer 8 as default) because XP was declared "dead" (end of life on April 8, 2014 - no more security updates) and the existing PCs aren't capable of running UEFI required for Windows 8...

Windows 7 and Windows 8 is going to get a free upgrade to Windows 10; it's not far fetched to believe some people are installing a fresh copy of Windows 7 on a clean machine to make use of the free upgrade.

There's definitely a huge difference between supplementing your HTML with some JavaScript and writing a JavaScript application.

JavaScript as a server side language is a new playing field, with different trade-offs, obstacles and design. I built an API service last year using Koajs (alternative to express), Gulp (alternative to grunt) and a bunch of other things.

Recently I've been looking into isomorphic JavaScript single page applications and have been learning a bunch of new things, such as webpack, yahoo isomorphic flux stack (fluxible, routr etc.) and application structuring.

You'll be surprised by how little you really know about JavaScript as a programming language till you start with server side and SPA development. I'd suggest you start off with building a traditional web application in Node.js (with gulp) before attempting SPA development. Also take a look at React and Babel.

Thanks for the write up. I'm mostly in agreement with your point of view.

I've setup this fundraiser on behalf of my friend (and donated myself). I know this is not exactly the right place to post this to, if you have recommendations on where to post it will be greatly appreciated

Over the past few years of being a HNer I know that the community can be compassionate, and for this I admire HNer's.

If you can help in anyway it would be greatly appreciated. He's located at Clovis, CA, and in need of shelter, food, some medical supplies and a job. He was employed as a (Network?) Technician at Schneider Electrical and previously Comcast.

Thank you for your consideration and time.

Sorry to say, but the design is change intolerant and will most likely fail to meet expectations. Changing the questions or answers will cause all current responses to be invalidated or lost when a question or answer is deleted. The sizes (e.g. varchar(200) for a question) aren't necessarily accurate - what about really long questions or answers?

Typically I'd expect to see:

- Survey (details + configuration)

- Questions (details + configuration; incl. the order)

- Answers (details + configuration)

Survey 1 - * Questions 1 - * Answers

A separate audit table is preferred if you plan to track who changed what and when (ref: "updated" on tables). I'd rather include a "started_at" and "completed_at" on the "survey_response", other metadata like user agent, IP, client time zone etc. would be pretty useful. There's other configuration that's also missing, e.g. from when to when is the survey available? what's the limit of responses? can someone complete the survey twice (or more)?

Overall I'd rate the current design 3/10. It might be good enough for a beginner tutorial, but for production purposes it's not. I'd suggest you go back to the planning phase and review how your design meets your (clients) goals and how realistic it is in terms of usage/ability to change/future needs that can be accommodated now (typically things such as how long it took to complete a survey, or other details - you can't get that data later on if it was never recorded when it was made available).

In the spirit of OSS I forked httprouter instead of just keeping the changes locally. I hope that the implementation can prove as a reference in improving httprouter or other Golang muxers.

I like httprouter, but dislike how the dependency on httprouter.Params pollutes your packages that need to expose httprouter.Handle.

I also dislike the non-standard handler, even with map[string]string parameters. From what I read the proper way to "scope" things in Go is to pass "it" as a parameter to a method; so the dislike is just personal preference. Currently the only way to retain the standard (http.Handler) interface compatibility is to use a synchronized reference map e.g. map[*http.Request]map[string]string, similar to Gorilla Contexts' implementation with only the parameters associated with the request.

Anyway, after all those changes it was a short jump to implement basic middleware helpers and expose an initializer with a standard implementation to associate the parameters with the request.

I hope that answered your questions and thanks for showing interest :) P.S. Check the updated example usage

Learning after school is self-study. Don't expect anyone (even a mentor) to teach you what you need to know.

Every job comes with different challenges and requires learning new things. You'll spend the first few years getting comfortable with the technical side of things. When the business side becomes a more important/bigger challenge than the programming side; that's when you know you're a developer.

My advice is this: identify role models in the fields/technologies you are interested in and follow them. Try to find someone who is more passionate about what you do than you (i.e. someone doing the same things as you but is better than you) and learn all you can.

One of the books I can highly recommend is Evan's Domain Driven Design, it makes it easier to reason abstractly about business.

From what I can tell, the IIS team is embracing OWIN. Be sure to check out Project Helios (http://www.infoq.com/news/2014/02/helios). *Helios can be compared to OpenResty in the sense that the application runs directly on-top of the (core) web server, instead of a plugin/pipeline.

In my humble opinion, self-hosting is useful as long as it's feasible to reinvent the web server wheel. In terms of IIS that can include url rewriting, caching, compression, performance tracing, critical error logging, request logging, endpoint configuration including SSL (and SNI), zero downtime deployments, graceful shutdowns and much more.

The programming tendencies nowadays is to build highly specialized software (high cohesion), with only the needed dependencies (low coupling) and a small surface area to promote faster iterations (micro services).

Based on the above observation, the approach of Microsoft to release and endorse a cross-platform <core> .NET is commendable and is exactly what we need right now.

There's much to say about the downsides of the bring-your-own-x composition approach, but I truly believe the issues we face today will be addressed over time as the discipline and dedication of the programming community as a whole increase due to the increase in responsibility.

I second this and would strongly advise this approach.

The courses available on Khan Academy help you visualize the math and gain a better understanding on the 'why' (reasoning) while also teaching you the 'how' (application).

There's sufficient math courses available to teach you everything from pre/primary school arithmetic to first year university/college level calculus/linear algebra.

I'm a fan of extension methods as well.

The pitfall to avoid with extension methods is that you should keep external dependencies low (e.g. only depend on System and System.Core for common reusable libraries).

You might even need to split such reusable libraries based on security context (e.g. Medium trust, Full trust) and capability (e.g. IIS Classic, Integrated Mode ~ OWIN).

I setup a local NuGet repository to host my reusable libraries (for myself and team). The versioning allows you to make breaking changes as necessary without breaking dependent applications. It's also feasible to then write well documented and tested, reusable code. See: http://msdn.microsoft.com/en-us/magazine/hh781026.aspx

Discussion on reddit: http://www.reddit.com/r/golang/comments/2n6zyj/go_ioc_packag...

I find the hardest part in any project is avoiding and getting rid of technical debt early on.

Technical debt, simply put, is the result of poor choices made due to the lack of understanding (mostly the business domain; including current and future requirements) at implementation time. "Gold plating", not validating or being able to validate assumptions early on and not following best practices are the major contributors of technical debt. (overdoing it and not knowing what you're doing)

Determining scope is essential to any project. Adding unnecessary layers (e.g. localization, internationalization, n-tier architectures, following patterns blindly such as CQRS, leaky abstractions), insufficient layers/abstractions and not validating important assumptions lead to dramatic increase in lead times.

Apart from learning from others' experiences, I found that being accountable to someone you can trust to provide you with advice and scrutinize your approach to be invaluable.

As you gain more experience you will start trusting your gut more in regards to technical and business decisions. The other party can't always provide you with correct, complete or sometimes any answers at all and they trust you to do what's best for them.

In regards to the discovery process, it's all about communication. Ask them to describe in a document what they want (functional requirements), what problems they are trying to solve and what constraints are in place. If it involves workflow, ask them to describe their workflow and distinguish different roles and responsibilities. This should at least open up some avenues of discussion to resolve ambiguity.

Once you have a good idea of what's going on, start to compartmentalize the different contexts and iterate over each. See: http://www.productbreakdownstructure.com/

Looks pretty good, I'm a big fan of the placeholder without input -> label + description when active -> label with input style.

If you find it hard to read, set the body style e.g. width:600px; margin:auto; font: 18px/24px Calibri,Arial,Helvetica; color:#333; background:#F3F3F3;

Honestly, I'm not surprised. It's been a long time coming.

The mental burden of having to learn something entirely new (without much guidance) can be frustrating - especially if you're forced to make the switch. Think about the last time you learnt a new programming language that was very different from what you're used to. E.g. going from a C style language to a LISP, or to something like Scala from C with no background on the JVM.

For most people, the thought of installing Ubuntu or whatnot would not cross their mind if their PC/laptop came with Windows. Nevermind that the average user just knows how to turn a PC on/off and use a few programs/websites. One reason why I think the LiMux revolution didn't sit too well is that the precedent for user experience nowadays are set on mobile platforms where everything is extremely convenient and require little or no configuration - it just 'works'.

Linux systems on the other hand tend to require a lot of intervention/hand-holding (e.g. chmod) and rarely come with wizards to simplify processes (e.g. try installing an unsupported USB WIFI adapter). The world would be a different place if kids grew up using Linux instead of Windows :). For that reason I vowed to teach my son some Linux basics and a few programming languages when he becomes older.

Well done!

Have you checked out MithrilJS (http://lhorie.github.io/mithril/)? It's similar to ReactJS in the sense you can use msx (jsx like templates) to compile down to JavaScript if you use something like gulp/gulp-browserify/mithrilify.

Something to keep in mind with ReactJS/MithrilJS is that in a lot of cases you will need to bring/build your own components, e.g. validation.

MithrilJS brings quite a lot to the table for its small code size (14 KB minified, 5 KB gzipped), e.g. built in http request (promise compatible), router, data-binding, IE 6+/mobile compatibility (requires XMLHttpRequest shim for IE 6, JSON2/3 and EcmaScript 5 shim for <= IE 7, otherwise no dependencies - see http://lhorie.github.io/mithril/tools.html) etc. The documentation is outstanding.

Just a tip if you want to try MithrilJS - a module is essentially an object that encapsulates the rendering of a component. The controller function initializes the component and the view renders it. The the controller and view functions are stateless (think static); the controller function gets called once to initialize state and the view - 1 or more times - gets passed the controller/state to (re)render the component. Calling m.module(<dom_element>, <module>) binds the module to the DOM element/renders the component into that DOM element.

I think it is pretty neat that you can use ReactJS/MithrilJS for SPA's (<!DOCTYPE html><script src=".../mithril.min.js"></script><script src=".../app.js"></script> example) as well as building in page views similar to what you would have used KnockoutJS for.