ionrock · HackerTrans

ionrock

no profile record

Submissions

Show HN: Chet – Record your commands to speed up local development

chet.monster

6 pointsby ionrock3년 전1 comments

Announcing pytest.el

ionrock.org

1 pointsby ionrock15년 전0 comments

Announcing TwitterBot

ionrock.org

2 pointsby ionrock16년 전0 comments

The Problem with jQuery as a Framework

ionrock.org

2 pointsby ionrock17년 전0 comments

A Geek and Musician's Notes on SXSW

broadcast.oreilly.com

1 pointsby ionrock17년 전0 comments

Transplanting with Mercurial

ionrock.org

1 pointsby ionrock17년 전0 comments

Python Indexing with BerkelyDB

ionrock.org

3 pointsby ionrock17년 전0 comments

A Contextmanager Based Connection Pool

ionrock.org

1 pointsby ionrock17년 전0 comments

Some Thoughts on Mercurial

ionrock.org

1 pointsby ionrock18년 전0 comments

comments

4개월 전discuss

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.

2년 전discuss

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.

2년 전discuss

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.

2년 전discuss

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.

2년 전discuss

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!

3년 전discuss

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 :)

3년 전discuss

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!

3년 전discuss

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!

9년 전discuss

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.

10년 전discuss

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.

10년 전discuss

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.

10년 전discuss

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.

12년 전discuss

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.

12년 전discuss

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.

12년 전discuss

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.).

12년 전discuss

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.

13년 전discuss

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.

15년 전discuss

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.

15년 전discuss

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.

15년 전discuss

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.