HN user

Communitivity

2,136 karma

Javascript/Rust/Erlang dev | github.com/BillBarnhill | mastodon.social/deck/@BillBarnhill | twitter.com/BillBarnhill | =Bill.Barnhill

Posts9
Comments732
View on HN

The article makes sense for me. I see it like the broken windows policy of software development. If you allow sloppiness in the small places, the places where you allow it will grow, until your code base is riddled with it. The fight for code quality is also a fight against damaging bugs and against exploitable vulnerabilities.

One big problem with the fight is that industry is incentivized to cut corners. '(Fast, Cheap, Good)..pick two' often results in managers picking fast and cheap. In some ways,they seem legally obligated to fast and cheap due to fiduciary responsibility to the stockholders. That's only if you look at the potential profit and risks from a very short term. Alas, that is what most of the world's businesses do at the moment. To paraphrase Dom from the Fast and the Furious, "We live our lives one business quarter at a time". Eventually Dom discovers the futility of that during the course of the series. Hopefully we will too, before we crash.

Bjarne Stroustrup said "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off". The same is true of Rust macros. When you need them they're awesome, but you should almost never need them - add a new macro as a very last resort.

I used lit for a project a couple years ago, and loved it. It had some warts, mostly around working with React components and the Shadow DOM. But it's barebones IIRC. One of the things I loved about it was that it was focused on implementing and using WebComponents via the standard, rather than re-inventing all their own thing.

This brings back memories. I enjoyed following the travels described in the She's a Flight Risk series. I never did quite buy that it was a hoax either, though perhaps I am too gullible. If Isabella V. was real, then I hope she's chilling on a tropical beach in Buenos Aires, or somewhere else.

MMW: This will be the death of Chrome.

I also do not see Google parting with something so critical to their advertising. With their own browser they control the full length of the wire between the ad-server and the user. Without it, they don't. Only way I could see this happening is if Google then released what they considered a better browser.

We've seen down that road. We know where it leads. Look at the imagined futures of games such as Shadowrun and Cyberpunk. This way lies an extreme dystopia for everyone except the ultra-rich.

Calendar.txt 1 year ago

I like this, but need more detail in my log and have too many things in a given day to have them all on a line. Had the following idea, and will try it out at some point. Call it calendar.md

Use calendar.txt format and method with the following changes:

1) Use markdown, with a top level heading of Calendar (so inclusion is easier) and the portion

2) Use :tag: instead of +tag. Tags can be run together (:tag:tag2:). This helps with Org mode compatibility

3) Third level heading for each event in day, following same format as calendar.txt

4) text under heading is for notes about the event

5) Searching and seeing info on event in day, or summary about day is no longer easy with grep. This is the biggest drawback from not using calendar.txt. Overcome by writing a tool mgrep that is specifically designed to search markdown files in a Markdown aware way (search headings or specific level of headings, show all headings under matching heading or just one level under, show all content under matching headings, search text and show either lines or section text is in optionally along with ancestry of headings).

6) Create CalendarMDMode, minor mode designed to facilitate calendar.md use and editing within Emacs, requires OrgMode, things like shortcuts for new date, new event, in-editor use of mgrep, etc.

7) Attempt to add CalendarMD support to Helix, which is my daily notes editor, using the as-yet unlanded Scheme based plugin system (see https://github.com/helix-editor/helix/pull/8675 )

A company can produce software that is two of fast to make, good, or cheap to make. A publicly traded company seems legally obligated to not choose good, because fiduciary responsibility is interpreted as what's good for short term gain.

I suspect this is because of a continuing rise in the percentage of home sales representing home purchase as an investment by an investor instead of purchase for habitation, but I have no citable research to back that up at the moment.

I called myself a Semiotics Engineer for 4 years, but the title didn't catch. I did domain analysis, logical model creation, concrete model creation in XML/OWL/KML, model review and improvement, semantic reasoning-based system design/implementation, and message system design/implementation. This was before the rise of ML.

This is fascinating work and sounds a little like the research my daughter says she wants to study (she's only a sophomore at UMBC right now, though). She hopes to get an internship in the summer of her junior year. She is interested in plant biology and bioengineering.

If I understand correctly, plants have RNA - would this mean new RNA-based lifeforms could also be found within plants?

Yggdrasil Network 2 years ago

There was the Locker project by Jeremie Miller (XMPP), but it failed to gain traction and I think he pivoted into a more small scale commercial effort with it IIRC. The telehash protocol of Locker was extremely interesting.

Kudos for creating this. However, as others have said, the HTTP/1.1 protocol is most of what is needed.

I do think there is room for improvement though. Not in the conceptual or logical HTTP/1.1 protocol, but in the physical over-the-wire implementation. I'd like to see a version of HTTP/1.1 designed to work with CBORS as the main over-the-wire format, possibly including support for CBORS over COAP.

"everyone is assumed to be acting in good faith". Right. I think that when it comes to network service security the old adage told to my father by an Irish Catholic priest applies: "Bill, once you understand that most people are just no damn good, then you'll be fine".

Or, in the words of the NSA, "Trust, but verify".

I agree that HTTPS is bad though, as it is used. We only do one-sided TLS, not mutual. Most people don't verify the server's cert by looking at it. Most apps don't encrypt messages before they go over TLS. In a more secure world a proxy with stateful packet inspection would not be possible.

As is often the case, the problem isn't technical (or at least not mainly technical). Employers, governments, and ISPs want proxies that inspect traffic, either for CYA or to increase budgets by increasing situational awareness. For governments, situational awareness increases wins by enabling them to catch people they deem bad actors. For employers and governments, increased SA means a decreased chance of leaks and people not doing what they're supposed to do with their time. For ISPs, it means they can monitor the traffic and restrict certain things (like video streaming, or running a server from home) to increase profit.

I can think of at least one potential solution. Still, it requires a technically savvy public, a patient public, and money: Open Source phones in everyone's hands, circles of trust, distributed freenet with data passed E2E encrypted via gossip protocol when two phones get near enough for Bluetooth data transmission (figure 50m roughly) where both phones are within some N degrees of separation via circles of trust. However, this mean's getting/sending data is asynchronous with long delays and no guarantees.

This is possibly why a number of Fortune 500 and government organizations avoid GPL like the plague. This whole debacle 'won' one battle for GPL licensing but set the war (and their stated ultimate goals) back by a significant amount. This event is a big topic among the devs where I work. It's reignited the 'we should make sure our policies state no use of GPL licensed code or libraries without the exception' (use of binary executables is unavoidable).

In any online population, some people like to build the world (Aces), some like to rule the world (Kings/Queens), some like to watch the world burn (Jokers), and some spend all their time fire-fighting (Jacks). Corollary: There will always be jokers.

No, it's not well-engineered (speaking with over 25 years as a professional software engineer), at least the portions of the code I have looked at. Things I vaguely remember (it's been ten years since I looked at it) are lack of data normalization (and not in a performance optimizing way), template includes that depend directly on order of inclusion and variables in other templates, very little code isolation, and PHP.

WP is a well-delivered product that works well for its user base in most situations. Plenty of code is well-marketed, profitable, and fulfills users' needs, but not well-engineered.

By the way, I know the PHP gripe is contentious, but it's not the reason why I think WP is badly engineered, it's just the reason it was easier to engineer it badly.

See https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ for more details on PHP.

One excerpt from that page:

There is a whole lot of action at a distance. Consider this code, taken from the PHP docs somewhere.

@fopen('http://example.com/not-existing-file', 'r');

What will it do?

If PHP was compiled with --disable-url-fopen-wrapper, it won’t work. (Docs don’t say what “won’t work” means; returns null, throws exception?) Note that this flag was removed in PHP 5.2.5.

If allow_url_fopen is disabled in php.ini, this still won’t work. (How? No idea.)

Because of the @, the warning about the non-existent file won’t be printed.

But it will be printed if scream.enabled is set in php.ini.

Or if scream.enabled is set manually with ini_set.

But not if the right error_reporting level isn’t set.

If it is printed, exactly where it goes depends on display_errors, again in php.ini. Or ini_set.

I can’t tell how this innocuous function call will behave without consulting compile-time flags, server-wide configuration, and configuration done in my program. And this is all built in behavior.

Regardless of where you stand on AI vs Artist divide, the claim that prompted AI work contains no human authorship is clearly false.

Let's suppose I as a blind muse conceive of an amazing vista and describe in painstaking step-by-step instructions how to paint it, to a person with no creativity but a gift for mechanical paint strokes. Does that have human authorship? I think everyone would agree. Some would say the author is mostly the muse and partially the painter, some would argue only the painter, but all would agree that in this situation the art cannot exist without the muse.

Next let's suppose I as a blind muse conceive of an amazing vista and have a device I can use to execute those painstaking step-by-step instructions in how to paint it. Does that have human authorship? Again, I think most people would say yes.

Now let's support I as blind muse have a device I can press buttons to execute preprogrammed macros of movement. Again, I think most people would say this has human authorship.

Finally, let's take the above example and say that instead of macros the blind muse has the ability to verbally describe their creation and the device executes the appropriate macros, appropriate being learned from the macro executions of many other artists (who should be compensated fairly btw). Human authorship? Yes. And we've just described Midjourney. If you agree the first scenario has human authorship then you agree this one does, because we're agreeing on human authorship being that the creative output of a human is the necessary input to create a work of art.

The marshalling cost might be negligible for come use cases, but the bandwidth usage definitely is not. I think the best interface description protocol is one where the serialization format is unspecified. Instead, the protocol describes how to specify the structure, exchange sequences, and pre/post-conditions. A separate document describes how to implement that specification with a certain over the wire format. That way the JSON folks can use JSON when they want (unless they are using large longs), and other folks can use what they want (I like CBOR).

I dug up a blog post of mine that's no longer on the net, from 2012. Some of the resources are likely still valid. The links did not come through, so you'll need to do some searching.

Top 10 Resources For Getting Started with Erlang

These are the top ten resources that helped me when I started learning Erlang. I've not ordered them within the list because they complement each other. Your mileage may vary. Other Erlangers opinions may differ. These helped me greatly though. I cannot stress enough that there is no substitute for making. The below will help you much more if you start out trying to solve with Erlang some problem you know about. Decompose it into very small pieces and take each piece one at a time. For some more info on that see the post introducing the concept of Deliberate Practice.

1. Learn You Some Erlang I started learning Erlang back in 2009 at about the same time Learn You Some Erlang chapters started being posted by Fred Trottier-Hebert. This is the first place I'd recommend someone go when they are learning Erlang, especially if they have good prior software writing experience. I found LYWSE easy to understand and packed with detail. Sometimes it goes into too advanced details for a beginner, but you can skip these and come back to them when you are ready.

2. Joe Armstrong's Thesis Reading this thesis is drinking direct from the source. Joe Armstrong is one of the three fathers of Erlang. The other two are Bjarne Da ̈cker and Robert Virding. Reading A History of Erlang (PDF) by Joe Armstrong won't teach you Erlang, but it's a very interesting read.

3. The Erlang Web Site Erlang.org has some good examples, the OTP Design Principles User Guide, the Erlang Reference Manual, the documentation for the Erlang OTP libraries (Erlang's stdlib), and an online self-paced course.

4. The Erlang-Questions Mailing List The people on this list are very helpful. Chances are that your question has been asked before, so search the archives first. As with any mailing list it can take time to get an answer, so I tend to just use the archive. The FAQ, a link to the archives and instructions for subscribing are on their web site: http://erlang.org/mailman/listinfo/erlang-questions.

5. Free E-Books and Other Web Resources The following books are good to use for times when you don't have time to get into the coding zone, or when you want to deep dive into a particular topic. Concurrent Programming in Erlang, Part 1 Erlang For Skeptics - An old, but still useful, e-book that you'll need to build yourself from this project site. It's worth it though. TryErlang.org - A free hands-on web tutorial for Erlang I remember going through some others, but it's been a long time and I don't remember them. If you read this and know of a good (and legal) e-book link then please post it in the comments and I'll add it below here, with credit.

6. Commercial Books and Podcasts I bought some of the books on this list, borrowed others. They are all recommended, but in this economy it's important to stress you don't need them to learn Erlang, but they will make your learning Erlang easier. Erlang in Practice by Kevin Smith - From all accounts a very good series of screencasts on Erlang Erlang Programming by Francesco Cesarini and Simon Thompson Erlang and OTP in Action by Martin Logan, Eric Merritt, and Richard Carlsson Building Web Applications with Erlang: Working with REST and Web Sockets on Yaws

7. Online Q&A sites If you have a question while learning Erlang the chances are someone else has had it as well. It's also good when you don't have a specific question but you have some time to spend on learning. When that happens go to one of these Q&A sites and search for unanswered Erlang questions, pick one, and then research it until you have an answer. Once you have an answer you can go back to the question and post your answer if there isn't one yet.

Stackoverflow is probably the best known Q&A site. It is a great source for detailed Erlang information in their Erlang questions. They also have a decent number of unanswered Erlang questions at any one time.

Another less well-known site is Quora (requires login via Twitter or Facebook). They are getting more popular and are more focused on social connections than score, whereas StackOverflow is focused more on the score. They a tag so you can find Erlang questions, but I've not found a link for unanswered questions, only for open Erlang questions.

8. Twitter Twitter is always a great source for information, and for a dialogue with people that may be able to answer your questions. Feel free to follow me and tweet me if you have a problem. I also try to retweet anything on Erlang that I find interesting. My Twitter id is BillBarnhill.

9. Source Code The best way to learn a language is by making useful software using that language. The second best way is to read good code, trace how it runs, and re-read until you understand what it does. Often this will lead into writing code to get the software to scratch a particular itch you have. The best source code to read in my opinion is the OTP sources, for the sole reason that they will be what you interact with the most. The second best is the Github account of Basho and the repos in it, because these folks know their stuff.

10. Erlang Projects I Recommend This one isn't a resource as much as some recommendations from me on projects to learn about byt looking at the materials the developers publish, the source code, and building.

Web servers and frameworks

For web serving I recommend Cowboy. I started out on Yaws, then switched to Misultin for most things, Mochiweb for some others. When Misultin went away I switched to Cowboy and haven't looked back. There's some caveats though. Riak uses Webmachine and Mochiweb, and if you want to use Erlang professionally you need to know Riak. So you need to at least be comfortable with WebMachine and Mochiweb. The web framework Nitrogen lets you use Mochiweb or Yaws, and you should learn Nitrogen. Once you learn Nitrogen I suggest you learn Zotonic, which is a Content Management System (CMS) like Drupal and is built on top of Nitrogen. If you are coming from Rails, or want something that feels similar, then I suggest checking out the Chicago Boss web framework

My empathy is with Automatic on this one, but I still think it's the wrong move.

"Now one could say that the license allows that and it's legal. Sure, but so is cutting their free access off. If WPEngine is just leeching and spending nothing on improving the product, there's no way anyone can compete with them on price. Open Source is expensive, people need to be paid."-jeswin

If companies can't use Open Source without the risk that the project could ban them from using it, even if the company adheres to the letter of the license (if not the spirit), then most companies won't use Open Source. Most companies I've dealt with would rather pay for commercial software and offload the risk onto the software company that use an Open Source project they view as risky in any way. Companies can already view Open Source projects as risky in a number of ways: lots of drama/turnover in a project, a single BFDL controls everything, viral license. For many projects the rewards from using it outweigh these risks.

However, all the above risks can be evaluated before a company decides to build using an Open Source project. If projects are seen as able to block availability unilaterally without a license violation, that's a risk that can't be evaluated before investing perhaps millions using it. Of course, this would all be evaluated and we'd live in a better world if companies heavily using an Open Source project decided to allocate 1% of the software engineering budget as a donation to that project.

I think it requires a third thing: long-term thinking.

Other commenters noted that Google and Microsoft had big piles of money and a decent moat. They have not created anything like Bell Labs. Google tried, with DeepMind.

The problem is that companies used to think about 5,10,20 years out. Modern companies are gauged and gauge themselves by metrics that are quarterly or annual. They, to borrow from The Fast and the Furious, are living their life one business quarter at a time.

I don't think you can build something like Bell Labs, PARC, or the Lockheed-Martin Skunkworks with short-term thinking.

Cool project.

That said, I never send the same resume to everyone. I tailor a resume for each job I apply to. This doesn't mean leaving off positions or lying. It does mean taking the work done in a position and giving it a slant toward the target job.

For example, let's say I created a web app that shows a sales dashboard, with stats visualization, from raw daily sales data.

Job 1 (applying for Front-End) - Created monthly sales dashboard web site using React, MaterialUI, SASS, Node, Riak, and D3. Dashboard provided grid-based summary over individual weeks, months, and years. It also provided configurable line graphs and pie charts for various sales metrics. Data pre-processing done with Sci-Kit. Later added sales prediction using Machine Learning.

Job 2 (applying for Data Analysis) - Analyzed raw daily sales data to determine data cleansing needed, and created tool pipeline using Python NumPy, SciKit, and scikit-learn. Integrated pipeline into Riak data source ingest, and then built sales dashboard web site to visualize the data. Provided ML model for sales prediction built with scikit-learn, with XX parameters. Model achieved YY accuracy with only a ZZ mean error.

Same work in both, but I highlight the tasks most relevant to the target job.

Other thoughts are that Latex is a good way to get a well laid out PDF resume (PDF is not the web, you should have two versions of your resume), and I agree with other commenters - the final product needs more polish if it was actually going to be used to produce a resume to send in (I think it's fine as a proof of concept though).