Maybe some devs here can help me, I was recently promoted to "head of AI" at my work despite being very outwardly ambivalent towards it. So I'm struggling to figure out what would actually create value instead of just being an expensive waste of time but still satisfy the higher ups AI lust.

My first idea that I thought would actually be useful was just setting up the architecture for an actual analytics database for us and then let them explore it with metabase (then letting them use Claude for their wow factor of exploring it with AI or whatever).

But now I'm somewhat at a loss, so any insight you all have would be really helpful!

cross-posted from: https://lemmy.zip/post/66993290

I released v0.3.0 of my LCARS Star Trek Niagara Launcher Theme project.

For anyone unfamiliar, Niagara Launcher is an Android launcher/home screen replacement with a clean vertical app list instead of the usual grid of icons. I like it because the layout is already kind of minimal and interface-y, so I thought it would be a fun base for making a phone feel more like a Star Trek LCARS panel.

Niagara Launcher: https://niagaralauncher.app/

My project started as me trying to make Niagara Launcher look more like LCARS, but it has slowly turned into a more general LCARS wallpaper/icon/theme generator. This update is probably the first one where it starts to feel like a proper system instead of just a pile of cool-looking experiments.

The big change is that palettes are now shared across the wallpaper generator, icon generator, and gallery. I added a lot more categorized palettes too, including:

• Classic LCARS
• Trek faction-inspired palettes
• Pride/identity palettes
• Regional/flag-inspired palettes
• Accessibility modes
• Retro computing colors
• Space/nature themes
• General mood/function stuff

There is also a custom palette editor now, so you can directly change the LCARS block colors.

The other big thing is that wallpaper panel rhythm and color mapping are separate now. Before, the shape/layout pattern also determined which palette colors got used, which made some palettes come out weird. Now the rhythm controls the panel proportions, while color mapping controls how the colors are distributed.

So rainbow, pride, and flag-style palettes can actually behave more like themselves instead of getting shoved through the old LCARS role-color pattern.

The icon generator has matching color-mapping options now too, and the gallery got cleaned up with better filters, no weird caps, and live local-font previews for installed Trek/decorative fonts.

Live site: https://yearbook-enzyme.github.io/LCARS-Star-Trek-Niagara-Launcher-Theme/

GitHub release: https://github.com/Yearbook-enzyme/LCARS-Star-Trek-Niagara-Launcher-Theme/releases/tag/v0.3.0

Still very niche, still very Star Trek, but it is getting a lot more useful now.

Support this channel on Patreon ► https://www.patreon.com/zoranhorvatGenerative AI can write code, but it cannot develop software on its own. Here is why the...

For a script I'm making, I'm looking for a way to either get the build output directory Gradle uses, or change it to something different.

I'm aware you could edit one of the gradle files in a project, but my script requires not altering the android app project (It only uses gradlew / gradle.bat that comes with it to build)

Is there some way to change gradle's build output directory, or if not, a way to get it from the command line?

I built Soundmoji, a small Android Auto beta that replaces emoji in read-aloud messages with short local sounds, then lets the rest of the text continue through TTS.

Free APK: https://soundmoji.nanocorp.app/downloads/soundmoji-v1.0.0-beta-release.apk

Landing page: https://soundmoji.nanocorp.app/

If anyone here has Android/AA dev experience, I’d value blunt feedback on permissions, UX, and edge cases. Support link for anyone who wants to keep it alive: https://buy.stripe.com/3cI7sM91ydTh22mboTePY10

I maintain LocalEmu, a free and open-source (Apache 2.0) AWS emulator. It started as a fork of the archived LocalStack Community edition. The goal is to keep a genuinely free, open local AWS emulator alive and maintained.

What it does:

• Emulates 132 AWS services on a single endpoint (localhost:4566)
• Pure-Python core, with real Docker engines for Lambda, EC2, RDS, ECS, EKS, and OpenSearch
• Point your existing AWS CLI, boto3, Terraform, CDK, or Pulumi at it, zero config
• No account, no auth token, no telemetry. Persistent state across restarts
• Optional fidelity knobs: IAM policy enforcement, throttling, latency injection, Lambda cold starts

Why I built it: kill the multi-minute deploy loop, drop the dev/test AWS bill to zero, and stop keeping real credentials on dev machines.

It's for fast local dev, testing, and learning, not production, and not bit-for-bit parity with the real cloud.

Repo: https://github.com/localemu/localemu Site: https://localemu.cloud/

Happy to answer questions, and feedback is very welcome.

The failure analysis in First Proof’s Appendix A describes something qualitatively different from the hallucination patterns studied in factual QA: models producing proofs that are fluently wrong, where the wrongness is concentrated in a small number of unjustified load-bearing claims rather than spread across obviously false individual facts. I have tried in this paper to give that pattern a precise enough description to be studied systematically. The taxonomy has four modes (F1: citation fabrication, F2: premise smuggling, F3: silent reformulation, F4: local-to-global gap), and my empirical audit of eight Flash proofs finds that F2 accounts for the failure in every case—even though it is the mode least targeted by existing mitigation proposals.

The obvious question this raises is whether it is possible to build a system that doesn’t produce these failures in the first place, as opposed to detecting them after the proof has been written. A prevention-oriented system would need to enforce, during generation, that every load-bearing claim in the proof is either derived from stated premises, grounded in a retrieved and verified source, or explicitly flagged as unverified before the output is returned. The failure modes described here are, I think, a reasonable specification of what such a system would need to prevent.