jasonpbecker

It was a blast.

Of course they are, and the order "reduce, reuse, recycle" are in that order for a reason-- reuse (via resale) is superior to recycling the product itself.

This looks killer for analytic workloads in app or even just basic data transformation/munging from a data lake.

It's unusual that Cuomo ran as an independent trying to "spoil"-- but NYC has such a large number of Democrats (like many US cities) that the more competitive and important election is typically the primary election (which determines who is running for each party). NYC has had a history of sometimes going other directions (as Cuomo's relatively high vote shows; having elected Michael Bloomberg many times, for example).

Mamdani won the primary for the democrats over Cuomo, but Cuomo decided to try and do an independent run to further challenge him.

We did the views on view thing once when triggers, at least how we implemented them failed. This became a huge regret that we lived with for years and not-so affectionately called "view mountain". We finally slayed viewed mountain over the last 2 years and it feels so good.

The people in charge are intentionally ignorant of things that _already exist in government_, like the OIG, 18F/USDS, etc. And since their actual goal is to slash and burn the government so that it's literally unable to function, thus justifying its total collapse since it no longer has capacity, they have to take out the people who actually look for corruption, look into social security fraud, improve government technology systems, etc who would see through and call this shit out.

It's never been about making government more effect or efficient-- it's the managerial equivalent of the "starve the beast" mentality.

A lot of services, (like Feedbin in my prior reply) and a lot of reader applications will permit different ways of viewing the data to get full content to appear even in truncated feeds. That said, non-full content feeds are pretty rare outside of corporate media.

I don't really know what you mean. There's a ton of feed readers, both from an application and server side. I don't really need a lot of organization, but I've never seen a reader without support for folders. If you need more than one layer of hierarchy at 50 blogs... I have no idea what you're doing. I follow like 250 blogs and have just two folders, maybe, and it's super maintainable.

Anyway, services like Feedbin have been going strong for a long time, have a rock solid syncing system with great tools for things like seeing frequency of posting and abandoned or moved feeds, folders, automatic filters, and broad support in the app ecosystem if you don't like their apps or web experience (which is very good).

RSS is absolutely extensive and has millions of users. It's at least as mainstream as Mastodon/ActivityPub, it's just not talked about as such, and that's _excluding_ Podcasts as a use case.

This feels like a case for a function.

> As someone who basically uses R as a nice LISP-y scripting language to orchestrate calling low-level compiled code from other languages

Except... this is exactly was R was created to do, with a focus on mathematical/statistical libraries written in things like FORTRAN.

R is great as a glue language for these purposes if the purpose of calling that low-level compiled code is largely to work with data and especially if that data is not so large/computationally intensive to work with that it does not need to be distributed across hardware.

All of these are fixed in the latest version (possibly just the beta that is about to be released to the store).

That includes OPML export (which remained available online but has returned to the app), arranging items (always possible throughout, but there were some new sync bugs that had to be worked out, IIRC), Go To Podcast (click the three buttons, last option in menu) from an episode, etc.

Of course you can use any number of ways to implement rich text or formatting. A lot of people want Markdown because of the portability of plain text. Markdown has served as a good mechanism for plain text formats that still can do a bit more. Ulysses would lose a significant portion of its audience if it moved to it's own syntax or some form of rich text or its own binary. A new audience would likely become interested-- though fighting Microsoft Word is ... hard to say the least.

Maybe that's where Ulysses wants to go, and its own implementation of some non-standard elements suggests that. But I also know people who will not use Ulysses because of its non-standard Markdown elements resulting in files that are less portable.

We have a four year old application, 10+ developers, 2500+ PRs, and I don’t think a line of erlang has been written by us. Maybe there’s one or two instances of calling an Erlang function in Elixir, but we’re 94.7% Elixir, 3.7% HTML, 1.1% JS, and 0.5% Other in our monorepo, full application.

Note: this has been abandoned in favor of http://nvultra.com/

Most of the time I'm using `filter ... where` for cases like these... for example

  select
    column_name,
    MAX(value) FILTER (where meta_key='total_rows') as total_row,
    MAX(value) FILTER (where meta_key='not_null_count') as not_null_count,
    ROUND(SUM (amount_in_cents) FILTER (WHERE EXTRACT(MONTH   FROM TIMESTAMP '2006-01-01 03:04:05) = 1) / 100.0, 2) as 'january_sub_total'
  FROM table
  GROUP BY column_name

These are default for Hugo parsing of Markdown—- https://gohugo.io/getting-started/configuration-markup/

I definitely want to see a monitor with Vision Pro-style eye tracking and hand tracking. I'd love for eyesight and subtle gestures to fully replace pointer devices.

Managing to leave out parking costs, which could easily be $50 in a garage is very convenient.

Also, I'd eat my shoe if more than 5% of cars entering Manhattan had 5 people in them. I'd guess the number is sub 0.5%.

A vote here for a SQL cell. I want folks to use Livebook and Explorer more, but a very easy win for data folks who are not familiar with Ecto and are mostly writing complex select statements would be a sql code block that can easily reference a connection.

That would let people who are getting into Elixir for data work run a query, get an Explorer.DataFrame, and interact further that way.

One way to think about this is that CSVs are poorly specified, and what specifications do exist are ignored by CSV generating processes from popular RDBMSs. The advantage of a binary format with a specification and approved standard that is adopted would be having robust test suites that are followed that makes data generation unlikely to produce a bad file.

In the case of text delimited files, it is simply too easy and too common to generate, from the start, a malformed file that other systems cannot read. Because data loss is inherent in a text-based format, folks don't even bother to check if the files they generate can be successfully interpreted by their own system. PostgreSQL, Oracle, and MS SQL will all gladly produce CSV files that cannot be read back successfully. I'm not talking about some loss of metadata, I'm talking cannot be read.

In the "real world", of course I run validations on the data I accept. A common one for me, since the files are essentially "append only" when they're updated is to check for meaningfully fewer records than previous data loads. That's my best way of determining that when the file was read, records were dropped or lost because of things like quoting being messed up or an incomplete file transfer.

It's still not great that a mismatched quote, which is quite common, doesn't even trigger a warning in the validation methods of these parsers.

Yes-- that's precisely what I'm saying. They should be better at validation, and my experience is that `data.table::fread` in R is the best in class.

I tried `polars` via Explorer from Elixir, and it shit the bed in an entirely different way:

``` df = Explorer.DataFrame.from_csv(filename = "my_file.txt", delimiter: "|", infer_schema_length: nil) {:error, {:polars, "Could not parse `OTHER` as dtype Int64 at column 3.\nThe current offset in the file is 4447442 bytes.\n\nConsider specifying the correct dtype, increasing\nthe number of records used to infer the schema,\nrunning the parser with `ignore_parser_errors=true`\nor adding `OTHER` to the `null_values` list."}} ```

Note, I added `infer_schema_length: nil` assuming that the data type discovery via sampling was just less good in `polars`, since this would have it read the whole file before determine types, but it still failed.

What you're saying is I should build and maintain my own delimited file parser with my own logic for healing these files and logging, rather than using any number of hugely popular delimited file parsers used by hundreds of thousands (millions?) of people with many strong programmers maintaining a well-tested code base.

The best way to do exactly what you're saying is just use R and do:

``` data.table::fread('my file.txt') |> arrow::write_parquet('new_file.parquet') ```

That will do the exact same thing-- sanitize the file, parsing and transforming the data correctly, logging questionable lines, and outputting a binary file that can be used by other systems later.

When you're working with thousands of files and hundreds of millions of lines every day and your client will be rightfully pissed if their data is off by $100,000 and my only resolution is to wait 2 weeks for someone in IT on their end upstream to _maybe_ fix the file, hopefully without introducing a new error...

Writing my own delimited file parser over a huge amount of community effort sounds like the worst case of not-invented-here syndrome ever. What stinks is how willing most of those projects are to fail silently.

A comparison of duckdb, PostgreSQL, pandas, readr, and fread when reading a delimited file with strange data.

Having written tens of thousands of lines of R code that I've been maintaining and using for production pipelines for 9 years...

Sounds like you worked with (or wrote) really bad R code.

The battery will be useless in 8-12 months if you keep it plugged in nearly 24/7.

We are getting tons of utility scale solar:

Utility-scale solar power generation in the U.S. is surging. This year, almost half the 46.1 gigawatts (GW) of generating capacity added to the grid will be solar, according to the U.S. Energy Information Administration, and solar has contributed more than 30% of all new capacity in five of the last six years.

https://news.sap.com/2022/11/the-take-utility-scale-solar-su...

Residential solar has no complexity for siting, transmission infrastructure, takes different skills to install, and let's relatively wealthy people move fast.

I am pretty sure all of his problems would be fixed with Feedbin, which offers a great in-browser interface, shows all the feeds on the page when adding a URL, and helps with the firehose issue with filters.

I also prefer Reeder to a large degree over NNW myself.

This massively underrates the cost and challenge of brine waste remediation and fails to account for the cost to our broader need to reduce carbon emissions by redirecting large solar projects to brand new energy uses versus replacing existing energy infrastructure.

Just an observation: the native apps that are better are built on massive, proprietary frameworks developed by platform owners. In some ways, most of the web frameworks are trying to be the One True Web Platform Framework that similarly makes it possible for developers to make better web apps the way that say, AppKit or UIKit makes that possible on Apple's platforms.

So I'm left wondering, did the frameworks fail or did the web developer community fail?