ionrock

I haven't tried this project, but did switch to vterm from shell-mode a while back because it managed to fix most of the paper cuts when using shell-mode. I also used to create a lot of custom compilation buffers for things b/c it would create links to files that were helpful, but that has been less helpful to me. At the end of the day, there were papercuts that made shell-mode and compilation buffers less ideal and most folks were focusing on traditional terminal support.

This kind of framework helps to optimize a bit for returning hypertext (iow HTML snippets) rather than leveraging a frontend system that only interfaces with the backend via an API. From that perspective, you need to be able to send HTML snippets precisely and manage more URLs that provide the snippets. React already has a pretty strong abstraction around HTML with JSX that has been generally morphed into web components. Writing the HTML components on the server using a library that maintains valid HTML is convenient, and it also means you can deploy an application without having to bundle a bunch of template files.

I will say I do think some opinions on how to structure URLs to return snippets might be valuable. Some of these frameworks leverage headers htmx sends to use just part of the page, but I think it is easier to just have individual URLs for many use cases. I've used Go and Templ in a similar fashion and one benefit with Templ is that the snippets are effectively functions, so returning the specific section and passing args is reasonably natural when breaking something out of a page.

Overall though, the goal is to avoid duplicating your data model and abstractions in the UI in favor of relying better networks, faster browsers, and HTML improvements to create interesting interfaces with simpler code.

Writing post-mortems is generally pretty kludgy. You might have a Slack bot that records the big picture items, but ideally, a post-mortem would include connections to the nitty-gritty details while maintaining a good high-level overview. The other thing most post-mortems miss is communicating the discovery process. You'll get a description of how an engineer suspected some problem, but you rarely get details as to how they validated it such that others can learn new techniques. At a previous job, I worked with a great sysadmin/devop who would go through a concise set of steps when debugging things. We all sat down as a team, and he showed us the commands he ran to confirm transport in different scenarios. It was an enlightening experience. I talked to him and other DevOps folks about Rundeck, and it was clear that the problem isn't whether something can be automated, but rather whether the variables involved are limited enough to be represented in code. When you do the math, the time it would take to write code to solve some issues is not worth the benefit.

Iterating on the manual work to better communicate and formalize the debugging process could fit well into the notebook paradigm. You can show the scripts and commands you're running to debug while still composing a quality post-mortem, as the incident is happening where things are fresh.

The other thing to consider is how often you get incidents and how quickly you need to get people up to speed. In a small org, devs can keep most things in their head and use docs, but when things get larger, you need to think about how you can offload systems and operational duties. If a team starts by iterating on operational tasks in Notebooks, you can hand those off to an operations team over time. A quality, small operations team can take on a lot work and free up dev time for optimizations or feature development. The key is that devs have a good workflow to hand off operational tasks that are often fuzzier than code.

The one gotcha with a hosted service IMO is that translating local scripts into hosted ones takes a lot of work. On my laptop, I'm on a VPN and can access things directly, where you need to figure out how to allow a 3rd party to connect to production backend systems. That can be a sticky problem that makes it hard to clarify the value.

After dealing with the current state of affairs regarding the front end, I think this is pretty interesting. I've been writing Go web apps with templ and htmx. I've punted on dealing with CSS using a cdn and bulma. I did get Tailwind and friends working, but it required a lot of work being outside a React/JS framework like next.js. It also felt really weird using npm to install CSS.

The nice thing about this is that you can get a tailwind Go lib to programmatically build into your binary. There are no extra files, one build step, and one binary output. After trying out Fly and Vercel, I went to running things with docker on a VM, and a single binary in a container makes things much simpler IMO.

This looks pretty cool and I look forward to seeing folks do interesting things with it.

While I can't say this is true for vim, in Emacs, I found that the customizability helps for a lot of different programing tasks. I run my terminals in Emacs and they are associated with my projects. Magit (the Emacs git package) helps me do complex rebases with diffs alongside creating branches and everything else you might do in git (even the reflog when things get rough). There is event a handy rest-mode that lets me write and save HTTP sessions. I connect to my database in buffer as well. What makes all this so handy is that I can move the buffers around to compare things side-by-side, use a single large buffer, etc. While VS Code has splits and terminals, I found that in Emacs I can access everything from my keyboard and now that I've gotten used it, I don't even think about it.

I've heard that a lot of vim folks get similar behavior via tmux and leverage other shell tools.

I'm not going to argue you should switch, because it is an investment. It is like owning a house, you have autonomy but you're also on the hook to fix the air conditioner. You also can't just drop it and move to the next editor. Your hands and workflows become tied to your editor. Keybindings may be similar, but it is not the full story. Either way, it is a journey getting good with your tools, so enjoy it!

I don't know if I fully grok the web components described by the author. I did find that using templ with Go makes it reasonable to have components you can inject some logic and state into for sending back HTML to htmx where it makes sense. The thing that makes sense is we focus on generating HTML once and there is no need to redefine models in the frontend. This is important because it means we don't take HTML, convert it to a data structure, validate the data, then send the data to a server, that has to validate things again, and return some resulting data, that once again gets rendered as HTML. Each data transition is expensive from a complexity perspective and requires caching state where caching is hard.

I'll admit that I'm not a frontend guru so my bias for writing apps like I did 20 years ago likely shows here.

Still, when I consider all the different abstractions and details around using something like Next.js + Typescript, and where the division between server and client becomes mixed, reducing complexity feels advantageous.

Tailwind is another good example where the explicit nature of attaching styles makes sense if you are writing React components. You've encapsulated all that noise behind a simple JSX tag. Using Tailwind with something that returns HTML then requires a similar way to encapsulate the noise. Again, I found using Templ with Go made that feasible, but I still have avoided Tailwind just b/c I don't want to introduce the noise too soon if possible.

It all makes me wonder if we lost the idea of a fullstack engineer, not because the problems became so challenging that we needed the extra complexity, but rather because we organized our applications into frontend and backend organizationally when we should have been more diligent in maintaining teams that could do everything.

The real tl;dr is that Templ for Go is pretty handy for writing components :)

I had a similar thought when I first looked at it, but then I thought about my browser history and URL bar. It is sort of a lot of work to open files to write scripts, keep them organized, and make them accessible just to make some commands simpler to run. I wrote https://github.com/ionrock/we for this very reason. I moved most args to env vars and made loading different env vars easily via files. Maybe the history is a better way to make these things reproducible and useful by avoiding the redirection necessary by scripts?

While I agree it may not work with everyone's workflow, maybe it could be a powerful change to folks workflow. I'm going to try it out and see for myself!

Chet is meant to be a helpful big brother that keeps track of how long commands take to run. It stores the timings in a local SQLite database so you can run queries to find opportunities to optimize. There is also a simple service where you can post timings so your whole team can measure things.

I know there are other similar tools out there, but I hope this one might be helpful or interesting to someone!

Personally, I think it is more convenient to think about things like this (ie firewall rules) as data, which makes the use of an API a convenient way to work with the data. The converse, in my mind, is that I'd have to configure each node and ensure a text representation of my firewall rules are correct. That opens the door for some thinking about concurrency that I thankfully get to avoid with an API like this.

That said, I can see your point that you are hiding some details from the OS that might be helpful such as what hosts you can talk to.

Fortunately, just because you might configure a firewall with an API rather than some Ansible plays, it doesn't mean that you can't continue to use Ansible to fill in the gaps. For example, if you did use Ansible to previously configure your iptables, you might change the playbook to call the API based on some YAML. You might use the same YAML to write some information on the host that your application can use to understand the firewall rules that are used.

The point being is that it is always good to remember these are not either/or decisions.

Lastly, I'll also speak up for those folks that don't know much about firewalls and iptables. I understand the principles, but I'm far from feeling confident managing that system myself. In my case, I'm really glad to have an option that lets me get the benefits without forcing me to operate a system I'm not well equipped to do.

Most services that might be considered "backends" (ie databases, queues, cloud services) end up being in written in languages that can safely use async techniques for I/O and still use real threading or some other method for managing CPU bound problems.

Many of the applications people think of for node.js end up being "glue", much like python, and can live within this constraint for a very long time, where the I/O optimization is a nice benefit.

While I don't know node.js very well and can't speak to the "shared memory server", I do think it is valid to point out that this sort of redesign to fit the platform is frustrating. I've hit similar situations in Python where an async i/o framework is used and at some point there becomes a CPU bound task. The application was redesigned and new microservices were started in order to cope and the architecture became convoluted. This sort of question always seems to always show up in Python where limitations of the GIL influences the design of the software, the libraries used and deployment. It seems node.js, not surprisingly, has the same problems.

As the above comment clearly points out, there are workarounds to make things work. Still, when I think about the amount of time and effort that goes into debugging systems when they hit limits like the author mentioned, I imagine most of the the benefits gained by using a language like Python or JavaScript go away.

As an emacs user, it is ironic I mention this tip!

You can use Control + [ as an alternative to using ESC in Vim. This solved my reluctance to reach for the ESC key in the far reaching corner of my keyboard.

This thread does remind me of nano. Maybe it is time to give it a try when editing files on servers.

It is really a chicken and egg problem. On the one hand, it would be good to refactor the code to help write some tests. On the other hand, you really shouldn't refactor the code with tests to prove that you haven't broke anything. In either case, you are correct that it can be extremely difficult.

While there is no easy answer, I've found that in these situations, I still try to write a test first. The difference being that I try to write a test that exercises the code at some API level that I don't want to break. These test start off really ugly and require a ton of work, but they ensure that refactoring the lower level code to make it more testable doesn't break things. Eventually, the tests and code at the higher level can be updated safely.

I've felt the same way at times until I realized the issue is just my perspective. OO provides an organizational tool for organizing functions and variables. The same thing can often be accomplished by changing the way code is organized.

For example, in Python, if I have two functions that implement a "download" operation, but they accept different types of locations, I could use different modules to implement them:

    from mypkg.endpoints import ftp
    from mypkg.endpoints import http

    ftp.download(ftp.info(some_ftp_info))
    http.download(http.info(some_http_info))

You can see that we pass the result of `ftp.info` to each, which is essentially defining its type somewhat reliably.

In OO, you can simplify things a great deal by encapsulating data in an object, as well as organizing functionality accordingly. I think (in Python at least) the same benefit can be accomplished by using modules for namespaces and grouping, like you would a class.

By using modules in this way, it is then possible to utilize types like you might in haskell as well as enforce immutability, assuming the "types" you create are immutable (like namedtuples).

All that said, I've yet to have the courage to enforce this sort of paradigm in a project. I worry that it would be prohibitively expensive to my fellow developers who may not appreciate the benefits. With that said, I would be interested if the paradigm would be reasonable over time.

One thing that is challenging in managing the boundaries is that often times our languages don't prescribe enough layering. We usually have modules, classes / functions and methods to define our boudnaries. The real world dictates we deal with networks, protocols and content types, yet our languages, environments and communities prefer to recommend simplicity at the language level.

I think functional languages have a more healthy appreciation for layering by nature of requiring functions to act on data rather than having mutable data types. I believe if we want to reduce complexity we HAVE to create more layered systems to scope the bounds of our complexity. The problem is many people see this as over-architecting things. With time, a design can evolve such that 10 or 20 layers, as compared to the 3 in MVC we often see, could be manageable with help from our languages and environments (IDE / text editor / etc.).

At some point I think it is important as a programmer to take pride not only in the result of the code, but the code itself. Efficiently managing a project can and should be rewarding as well. Developer usability is a very important feature. As a programmer, we write and iterate on code until it is ready to be published to the upstream repository. Our tooling has come about to help take our rough and ugly hacks and massage them into well written code we can be proud to push.

Also, banging out code is overrated. I've found that when I take time to think, my actual coding becomes closer to what you see in the movies. I can find my flow and quickly materialize my ideas, and most importantly, solve the problems that arise. When I try to just "code" it ends up being poorly designed and written.

The point here is that when you do have the desire to "just code" take a step back and consider taking pride in the code you publish. The tools and systems in place are there to make you a better code publisher. The goal is to write well written code that others (including yourself) can maintain. Rather than being frustrated you have to deal with the intricacies of rebasing or 3-way merges, take a moment to understand these skills will help you publish better code.

The thing about techcrunch's response is that the guy doesn't even try to make something work. If Ycombinator and other start ups decided to stop doing anything with techcrunch it would be over. Obviously TC has clout, but that doesn't mean they should piss in the well and ignore a great story. They should have capitalized on the fact that Chad stuck to his guns and seen if they could make it work. The could have posted the video themselves and tried to be innovative. Instead they wasted his time and treated him poorly.

Gittip is a great concept and Chad has done an amazing job building community based on the ideals of the community. He has created something that has value. I'm glad Techcrunch doesn't get to leach off his innovation and creativity.

Do they provide a simple app that you can use easily with a phone? I'd say the "social" aspects are where the benefit is. Being able to let one person pay the bill and everyone else just send their part seems handy.

One caveat before commenting is that I haven't written a major app in Node.js and I use Python most of the time (vs. Java).

I don't think the decision to use Node.js should be based on the fact it uses Javascript. Currently, Javascript has a much more interesting ecosystem than it has at any other time. Just as Rails took many collective practices and managed to communicate them clearly to a huge group of developers, I think a similar trend is happening in Javascript. From this perspective, Node.js is appealing because it rides atop this Javascript revolution with tools like Coffeescript, Backbone, etc.

Outside of the language decision, I think people are choosing to use Node.js b/c of its programming model. There are many applications that are relatively easy to code for when you can assume a constant connection between two processes. Where Node.js seems to excel is in these service level, socket based servers that may or may not have a web component. Likewise, Node.js also aims to be very nix friendly in that it tries to use simple processes for scaling instead of relying on more complicated application / language specific tools. This adherence to nix patterns is also very advantageous to some people.

Finally, as people start finding use cases where async really is a good idea, Node.js ends up being a decent option. Having done some async programming in Python, it is very difficult because the async assumption needs to be made throughout in order to avoid blocking. My impression is that the experience in other languages is similar, where no library is truly able to make the async paradigm seamless. Node.js has been written from scratch to support this model and many developers understand it via their Javascript experience. It therefore can be a good option when compared to including something like Stackless, EventMachine, etc. in their applications.

I think the key point here is that Node.js has managed to hit something of a sweet spot in that it is async, uses a language that is having something of a renaissance and uses *nix to make its integration obvious.

Again, I don't use Node.js very heavily at all, but that is my impression as to why people would choose it over other technologies.

I agree that for the most part this is correct. But, I also would argue that some aspects of a language can lend itself to more organized code. The include statement is one example where I think PHP doesn't help keep code organized. An actual module system with packages helps a good deal here.

Personally, I'd avoid node.js. It is most definitely cool, interesting and has been proving itself useful, but (!) there are a lot of details that won't come up until you really need them. If you're focusing on business logic and you already have a rather large set of applications that are relatively "bleeding edge", then I'd stick to a language that has a bit more history on the basics.

It is the really simple things like form parsing and cookies/sessions that may not be fully fleshed out in Node.js. Not that it won't be soon, but it is a nightmare to spend time on low level issues when you don't have to. This has always been the issue trying new languages and frameworks for projects. I get part of the way there and realize that some basic aspect of web development hasn't been done. Sometimes I start to handle the issues, but if the project is something I want to finish, it usually ends up with me turning back to Python. This might be a bad reflection on myself, but when you want to get something done that doesn't need the latest/greatest tech, it is nothing but frustrating to hit your head against a wall doing basics.

Just my two cents!

Hopefully the folks at Heroku see this comment as the idea for a cutoff rate is really good. I'm not sure cutting the bill in half is necessary, but describing the real costs of their service and potentially allow paying only that cost or at the very least a payment plan seems reasonable.

I like your perspective on this design decision as it seems to make clear what the intent could be. Alex reveals that the difference in Python is not so much the syntax as much as it hints at Python's treatment of functions as first class objects. This is really similar to Javascript where you can pass functions around for later evaluation. It adds a different level of complexity, of course, but it is something that I have appreciated in Python a great deal.

I chose a VPS b/c I wanted to run Python web apps, which traditionally don't work with shared hosting environments. Most shared hosts have daemons that kill long running processes. If you have a python script running for a long time (even if it is running your site) it would be killed. This seems to be the biggest reason in my mind for running a VPS over a shared host.

In terms of cost, a VPS usually will cost more as memory usage is something you'll have manage. For example, I would have liked to run MongoDB on my VPS but just didn't have anywhere close to enough memory. Not a big deal, but if you're using it for a business then it is important to understand what you're getting into in terms of memory usage and what services will need to run. You have to allocate resources for not only the web server, but any databases, scripts, etc.

I wanted to second this. I do the same thing. We use IRC at my company and we all work remotely. Having IRC in my editor makes things much simpler since I can easily copy/paste code, visit links and generally stay in one environment all day.

One of the biggest productivity boosts I've found working with something like Rails (I use Python but any web development system that involves starting up a local app server would be the same) is having an easy way to start up the entire application stack. For example, I have to start around 10 different services to run the app I work on. In Emacs, I've created small functions to start them up within some shells (all within emacs) and that lets me not only get started quickly, but quickly go to any of the services I'm focusing on for checking logs, viewing exceptions, copying output, etc.

On a more personal preference, my Emacs usage lead to use StumpWM and Conkeror (web browser) which help to keep all my keybindings very cohesive. A tiling window manager is really helpful b/c you never have to slightly move or resize windows. It sounds like Divvy does a similar thing.

That said, I bet if you take some time to commit to something like Vim (or Emacs!) it might eventually be more productive than TextMate. Emacs helps to keep everything within the editor (email, IRC, shells, etc.) while Vim helps to keep you in a terminal and to use standard *nix tools. Both tactics are very helpful IMO.

Sorry, but that is the majority of softare development. While you may believe all your previous accomplishments were really great, there is most likely someone looking at your code thinking how frustrating it is to work on the codebase. I think it is way easier to start from scratch than take an existing project and move it forward. When you start over, you can build a ton of momentum. You can hold all the complexities in your head. You rarely have the same problems existing solutions have because existing solutions have users that have learned the system and have a set of expectations.

I'm not trying to belittle your previous work, while at the same time you should realize that your frustration with maintenance is somewhat belittling as well. It is simply a different kind of problem that takes a different set of skills and talents to do well. If you consider maintenance in this way, it can be just as rewarding and help further your learning. Likewise, if you are doing maintenance, you are working on software that had some level of success. No one will ever ask you to change a codebase no one uses. You can learn a ton from a codebase that has been around for a while. You see the parts that were bolted on and how that impacts the future, but also how the tradeoff of a more flexible design was actually not necessary.

I'm not trying to be negative, but rather challenge you to change your mindset. I maintain a huge amount of code and it is a huge pain in the neck at times. That said, I also realize that my ability to continually dive into new parts of the code has become easier through time. Even if I do have to read the 1000 lines of code, I'm finding that the process of reading code and making guesses where to read next has become more efficient. Likewise, I've tooled my environment to help me search for leads when solving problems with the code. My perspective on writing new code is radically different because there is a very clear understanding of how I could do a better job for the developer that looks at the code in the future.

In short it can be really frustrating to maintain code, but at the same time it is something that needs to be done. I also believe it can be something done very well. If you see it as a healthy challenge I think you'll find the feelings of burnout will subside and you can take pride in changing that one line that ended up helping save people massive amounts of time and money.

Honestly, I program in Python every day and my biggest complaint is that duck typing and dynamic types as a paradigm is not well suited for large projects (like the ones I work on). When the codebase is larger than you can keep in your head, the types become a huge issue. When a bug is at one level of an application you have to figure out what argument was passed in. In a language like Java or C#, it is trivial to follow the trail of objects. In Python, it is cumbersome to say the least. Likewise, if you do adopt duck typing you will eventually find that there is no way around dispatching via types at some point. Again, it is not that huge of a deal, but it ends up being boilerplate-ish code you don't want to write.

Tests are effectively the answer, but they are a pain to write and having to document your type information via tests seems a lot more cumbersome from just doing "int my_var".

The party line with Python and dynamic typing is true in many cases, especially when starting a new project. As time goes on though, things get confusing and tests are rarely good enough to offer the same contract static typing offers. To say "you're doing it wrong" is somewhat correct, but no one does it right all the time.

I think the speed is always a feature, but at the same time, caching always feels more interesting in terms of a proxy. For example, where I work, we're able to use one server and proxy massive amounts of traffic to a cluster of services. I know we paid for this tool and it has proved to be worth the money. That said, it does a great deal more than just caching where even if there were a faster caching solution, I'm not sure it would be worth paying for.

I hope that makes sense since simply stating "there are already those kinds of programs available" does mean that there isn't room for improvement. The evolution of lighttpd, nginx and cherokee all suggest that people found apache limiting in some way.

As for the service it did feel pretty darn fast, so kudos for that. More use cases or a more general caching proxy/load balancer might be something more people could consider worth paying for but that is just my own thought.

Good luck!

I've always had mixed opinions of color-theme and this really makes it easy to get right. Thanks!