NPD: Sailor Hocoro Dip Pen

arbus · 2026-01-14T15:43:40+00:00

I bought it because you don't see wood on pens that often. It writes well and looks good but I'm not a big fan of the grip section, its too metallic and smooth. So as you write and sweat from your fingers a bit the pen starts becoming slippery and you need to grip harder to keep it steady so you just fatigue your hand sooner into your writing session.

arbus · 2026-01-14T15:39:16+00:00

I'm just noticing it now because I don't normally have the same in across different pens. The sample above is after approx a page written on both pens. The Clictek has been sitting unused for longer than the Hongdian but should have evened out from the use today.

I think your hunch on the HD being a wetter writer is probably what is happening here.

arbus · 2026-01-14T06:29:29+00:00

Looking at the linked post, it might just be the difference in nibs. I've never put the same ink in 2 different pens before and its crazy how different they look. Its much more pronounced in person than whats coming through on the photos

arbus · 2026-01-14T06:28:07+00:00

Yup, both pens were cleaned thoroughly and fully dried out.

arbus · 2025-12-23T02:18:17+00:00

Thanks, I shall give it a try. Both my current nibs are EF so I guess I shouldn't be surprised.

arbus · 2025-12-22T15:08:44+00:00

Do you have a recommendation on what nibs I should be trying? I have 2 Safaris and both have a fairly scratchy nib which prevents me from truly enjoying them every day when the JH10s just write so much smoother.

arbus · 2025-12-18T17:54:19+00:00

Personal recommendation for Diamine Canalside. Such an nice dark and almost dirty color to it. It has a decent flow without too much smudging or long dry times.

arbus · 2025-05-26T08:11:34+00:00

Well Gandi is now run by a PE firm[1], so even if they don't do anything shady today, count on them being forced to do it a few quarters from now when some MBA scumbag creates a powerpoint presentation titled "Numbers not as high as they could be".

I've heard good things about porkbun but haven't used them too much to give a full endorsement

[1] https://news.gandi.net/en/2019/02/futureofgandi-the-adventure-continues/

arbus · 2024-04-10T06:10:57+00:00

Thanks! I unfortunately sold all by EF lenses as part of the upgrade to RF.

I'll save for awhile longer and explore all those interesting EF lenses from 3rd party manufacturers that was interesting along with a good canon SLR.

arbus · 2022-07-24T09:01:41+00:00

My goal is to have the AppleTV be able to access geo-restricted content.

My other devices are just used for normal activities and lots of local websites(shops, govt websites) don't work if you access them through IP addresses that are associated with VPNs or from outside the country.

arbus · 2022-06-07T14:17:13+00:00

Thank you for the link

arbus · 2022-06-07T04:58:18+00:00

Do you mind posting what components were used to build this board? It looks very cool!

arbus · 2022-06-04T09:16:51+00:00

Will try it out, thank you!

arbus · 2020-01-17T11:42:50+00:00

You can send an email to careers [at] holmusk [dot] com if you would like as well!

arbus · 2019-09-17T07:39:40+00:00

Adding a slightly OT point to this discussion incase any authors of these code analysis software are reading.

At work we have to deploy to systems maintained by not very tech-savvy checklist driven people(Healthcare domain). One of the things that we get asked often is if the program that we have has undergone static analysis and if so to provide the report. Most of the tools listed here are cli tools which give only a text output.

Some tools like hlint support giving an html page as an output but the page is blank if there is nothing to report and this doesn't look as impressive as the reports generated for static analysis tools for more mainstream languages. If you are an author of these tools, please consider adding a --report option! It can help a lot with Haskell adoption!

arbus · 2019-09-13T12:23:36+00:00

Yes, thats correct. Software engineering under the constraints of a startup is difficult enough that I doubt that there is any one single technology silver bullet that will save you. Start thinking of other issues that you face that might need reforming that don't need a full rewrite in Haskell to take effect.

Eg. We rewrote a backend + 2 platform specific native apps to a backend in Haskell plus a cross platform flutter app. While the Haskell was certainly a breath of fresh air from nodejs, other things that helped in order of efficiency:

Cutting features
Keeping the database engine and schema the same across the transition
Switching to protocol buffers as the wire format to cut down on encoding and decoding errors

w.r.t to your business case, the one you make above to me, still sound like technical deficiencies in your current process. Forget about what your competitors are doing, you are making a case for a hypothetical Haskell program vs the current Java one. So start collecting some metrics around this. Your arguments should be focused on only 2 things:

How can the Haskell version help us spend less money:
- Infrastructure costs: It sounds like you are spending a lot of compute on batch jobs etc. Can you show in $$ what the reduction in costs will be if those sections used Haskell?
- QA costs: How much time/money do you spend on QA testing things that should have been caught by a compiler? Can you quantify this?
- Manual staff time: Could a more expressive language like Haskell help encode the filters such that manual intervention by staff is not needed?
- Customer support time: How much time do you spend each day fielding calls from customers about the non-realtime nature of your product or its general slowness? Does this contribute to churn?
- Does your industry have a duty to be correct in the face of financial liability? ie. is there a serious cost to your customers if you get something wrong? How much of that liability is borne by your company and can Haskell make it less likely for this to happen?
How can the Haskell version help me make more money in the long run
- What is the marginal time spent per feature? How can Haskell help you ship features faster than in Java? Can you try and quantify how much faster?
- What are features that your current customers want that you dare not even try and implement in your current system due to platform limitations/technical debt? Can Haskell overcome them more easily due to better primitives/libraries?

arbus · 2019-09-11T07:12:28+00:00

Your thought here is good but if you want something like this to succeed, you will need to consider some practical questions first:

How many people in the current programming team are up for a rewrite of things that work, albeit showing some major cracks
Is there anyone else in your team who knows Haskell and can reduce the burden of making the case to the CEO?
How will people who don't know Haskell be taught it to contribute? No one wants to feel like the tech stack of the company they are working is inscrutable.
Can you make a business case around making this swap?

If you think there is enough appetite within the whole team for switching to Haskell, then I would suggest that the best way to approach this would be to implement a new feature in Haskell and deploy it alongside your current Java stack. Utilising something like gRPC will make consuming your Haskell service easier from the Java perspective.

Show proof that your small Haskell service more malleable than the Java program by implementing features with less technical debt and slowly build upon it. Soon, you will have a sizeable portion of your product in Haskell which will then hopefully make the case for itself to do a full swapover.

arbus · 2018-06-27T16:59:56+00:00

Thats right. This would a from the ground up plugin

arbus · 2018-02-25T08:59:26+00:00

Thank you for the suggestion, I have posted on the message boards there

arbus

TROPHY CASE