今日已更新 257 条资讯 | 累计 24543 条内容
关于我们

标签：#github

找到 1155 篇相关文章

开源项目

🔥 notionnext-org / NotionNext - 使用 NextJS + Notion API 实现的，支持多种部署方案的静态博客，无需服务器、零门槛搭建网站，为Noti

GitHub热门项目 | 使用 NextJS + Notion API 实现的，支持多种部署方案的静态博客，无需服务器、零门槛搭建网站，为Notion和所有创作者设计。 (A static blog built with NextJS and Notion API, supporting multiple deployment options. No server required, zero threshold to set up a website. Designed for Notion and all creators.) | Stars: 11,496 | 44 stars this week | 语言: JavaScript

2026-05-31 原文 →
开源项目

🔥 JiyaBatra / CODEVIBE- - CodeVibe is an interactive learning platform designed to hel

GitHub热门项目 | CodeVibe is an interactive learning platform designed to help beginners understand programming through simple lessons and hands-on practice. It includes structured course sections, coding examples, and a built-in HTML compiler that lets users write and test code directly in the browser, making learning web development practical, engaging. | Stars: 28 | 2 stars today | 语言: JavaScript

2026-05-31 原文 →
AI 资讯

Three TODOs, three weeks, one weekend: finishing pq v0.14

This is a submission for the GitHub Finish-Up-A-Thon Challenge What I Built pq — jq for Parquet. A 50 MB Rust single binary that wraps DuckDB's query engine in a jq-style expression DSL, optimized for terminal one-liners and unix pipes. $ pq sales.parquet 'group_by .country | sum .revenue | top 3 by sum_revenue' ┌─────────┬─────────────┐ │ country ┆ sum_revenue │ ╞═════════╪═════════════╡ │ US ┆ 19065.00 │ │ FR ┆ 999.99 │ │ DE ┆ 312.00 │ └─────────┴─────────────┘ Where it started. I work in adtech. I look at parquet files dozens of times a day — campaign deliveries, partner exports, audience snapshots. Every existing option was painful: Tool Pain pyarrow / pandas 5-second cold start, 200 MB virtualenv parquet-tools JVM, slow, no query support pqrs Inspector only — can't filter or project duckdb CLI Great engine, but SELECT email FROM 'file.parquet' WHERE country='US' is too verbose to type 50 times a day Spark Are you serious pq is the tool I actually want — single binary, no JVM, no Python, jq-style syntax for piping into the rest of the unix toolbox. It's been my default cat for parquet since v0.5. Demo Repo : github.com/thehwang/parq Latest release : v0.14.0 (this submission) Install : brew install thehwang/parq/pq Tutorial : doc/tutorial.md — 30-minute hands-on walkthrough A taste of what shipped in v0.14: # Streaming JSON output (was the only buffered format until v0.14) $ pq big.parquet '.id, .country' -o json | head -c 200 # returns instantly even on a 40 GB file # Schema-drift gate for CI $ pq diff baseline.parquet candidate.parquet # Schema diff - a: ` baseline.parquet ` - b: ` candidate.parquet ` ## Added (1) | column | type | nullable | |-----------|---------|----------| | ` country ` | VARCHAR | yes | $ echo $? 1 # exits non-zero on drift, slots into CI without scripting And the new TUI Explain panel — press capital E for EXPLAIN ANALYZE , get row-group pruning per scan (this is exactly the panel you see on the cover image at the top of this post): Expla

2026-05-30 原文 →
AI 资讯

Coding agents should not hold write credentials.

I have been thinking a lot about coding agents lately. Not really about whether they can write good code, because usually they can, sometimes they can't. That part is obvious. But the risk is shifting from wrong answers to wrong outcomes. The part that feels more important to me is this: should the agent actually own the write authority? We already don't trust humans without roles, limits, reviews, and accountability. Developers use PRs, pilots use checklists, bank clerks have transfer limits. Capable agents need the same structure, but machine-readable. Right now a lot of setups still look roughly like this: agent reads the repo agent decides what to change agent has a GitHub token agent creates commits, branches, or PRs I don't think this is the right default. The agent can reason. The agent can inspect files. The agent can propose changes. But the moment it can directly create external impact, the problem changes. It is no longer just: did the agent say something wrong? It becomes: did the agent create the wrong outcome? That is a much more expensive failure mode. Intent is not authority The pattern I like more is simple: agent reads directly agent proposes intent a boundary decides an adapter materializes only admitted work So the agent does not get the write credentials. It submits a structured intent instead, which could look like: { "operation" : "write" , "target" : { "repo" : "example/app" , "branch" : "main" , "path" : "docs/config/agent-policy.md" }, "source_state" : { "blob_sha" : "8f31c2..." }, "requested_effect_hash" : "sha256:..." } This is then not a command anymore, it is a suggestion, or an intent. The system still has to decide whether this proposed outcome should exist. That decision layer can check things like: is this actor allowed? is this repo allowed? is this path in scope? does the source state still match? is this operation allowed? was the same effect already created? should this become a reviewable PR? Only after that should there be an

2026-05-30 原文 →
AI 资讯

Finishing My Personal Website: Mobile-Friendly, Dark Mode, and a Better Projects Section

This is a submission for the GitHub Finish-Up-A-Thon Challenge What I Built I revisited my personal website and decided to turn it into a more complete and polished portfolio. The project originally started as a simple personal website hosted on GitHub Pages. While it was functional, many planned features and improvements were never completed. For this challenge, I am working on improving the mobile experience, adding dark mode support, enhancing the Projects section, improving SEO, fixing existing issues, and making the website more interactive and professional. My goal is to transform an unfinished personal website into a modern portfolio that better represents my work, skills, and projects. Demo Live Website https://ehsankahrizi.github.io/ GitHub Repository https://github.com/Ehsankahrizi/Ehsankahrizi.github.io Current Status This project is currently being improved as part of the GitHub Finish-Up-A-Thon Challenge. Planned improvements include: Better mobile responsiveness Dark mode support Enhanced Projects section Improved SEO More interactive user experience Better website performance Additional pages and content Fixing existing usability issues The Comeback Story When I returned to this project, I realized that many ideas I originally had for the website were still unfinished. Although the website was online, it still had several limitations: The mobile experience needed improvement. Dark mode was not available. The Projects section was incomplete. The contact functionality needed attention. SEO optimization was missing. The website relied on a mostly single-page structure. User interactions were limited. Performance could be improved. Instead of starting a new project, I decided to revisit this existing one and finally complete the improvements that had been postponed. This challenge provided the perfect opportunity to continue development, clean up the codebase, improve the user experience, and turn the website into something I can confidently share with ot

2026-05-30 原文 →
← 上一页 下一页 →