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

标签:#OMB

找到 7 篇相关文章

开发者

Source View Technology: Combining the Strengths of APT and AST

Background Take Lombok as an example: at compile time, it reads annotations like @Getter and @Setter through an Annotation Processor (APT, Annotation Processing Tool), then directly modifies the AST (Abstract Syntax Tree) in memory, injecting getter/setter methods for fields. Developers only need to annotate fields, and the compiled .class files automatically include these methods. Advantages of APT APT is an extension mechanism natively supported by the Java compiler. Annotation processors run at compile time and can read annotation information from source code to generate new source files. Its advantages are: Standardized — Simply implement the Processor interface; no need to hack the compiler Composable — Multiple annotation processors can work together in the same compilation process Generated code is visible — Source files generated through the Filer API are located in the build/generated/ directory, and IDEs can navigate to them after configuring the source path Disadvantages of APT APT has a fundamental limitation: it cannot generate a class with the same fully qualified name as the source code. The Java compiler explicitly specifies that two classes with the same fully qualified name are not allowed in the same compilation unit. Source code generated by APT participates in the same round of compilation as the original source code, so it can never generate a class with the same fully qualified name as the original class. This means APT cannot truly "modify" a class; it can only generate new classes (such as Builder, Factory, etc.). Advantages of AST Tools like Lombok bypass the APT limitation by directly modifying the AST in the compiler's memory — injecting methods for fields, injecting constructors for classes, etc. The advantages of AST modification are: Can modify existing classes — Methods are added directly to the AST in memory, breaking through the limitation that APT cannot generate Same-Name Classes Zero intrusion — Classes written by developers rema

2026-07-18 原文 →
AI 资讯

RoomCraft AI: optimizar la distribución de una habitación con Simulated Annealing

Colocar los muebles de una habitación es un problema de optimización con muchas restricciones: la cama no va delante de la puerta, el escritorio quiere luz natural, hay que poder circular. Hay un número enorme de disposiciones posibles. RoomCraft AI las explora automáticamente a partir de una descripción en lenguaje natural. El pipeline de tres etapas Parser con LLM: el usuario describe su habitación en texto libre ("un dormitorio de 4x3 con la puerta al norte y una ventana al este"). Un LLM ( Llama 3.1 vía Groq ) lo convierte en una estructura de datos validada con Pydantic : dimensiones, aberturas, muebles deseados. Latencia: <1s. Optimizador con Simulated Annealing: aquí está el corazón del proyecto. Visualización y export: los layouts se renderizan en 3D en el navegador con Three.js y se exportan como plano técnico en PDF con ReportLab . Por qué Simulated Annealing El espacio de disposiciones posibles es combinatorio y lleno de óptimos locales. Una búsqueda voraz se queda atascada en la primera solución "decente". El Simulated Annealing imita el enfriamiento de un metal: al principio acepta movimientos malos con cierta probabilidad (alta "temperatura"), lo que le permite escapar de óptimos locales; según baja la temperatura, se vuelve cada vez más exigente y converge. Es una metaheurística ideal cuando el espacio de soluciones es irregular y no tienes gradiente. La función objetivo puntúa cada disposición de 0 a 100 según ergonomía: espacio de circulación, relaciones entre muebles, acceso a luz y aberturas. El sistema devuelve el top 5 de layouts, no solo el mejor, para dar opciones. Rendimiento Parse: <1s . Optimización: 2–5s . Export PDF: <1s . Footprint en reposo: ~100 MB de RAM. Qué aprendí Que combinar un LLM (para entender lenguaje) con una metaheurística clásica (para optimizar de verdad) es un patrón potentísimo: el LLM traduce el problema humano a uno formal, y un algoritmo determinista y barato lo resuelve mejor —y de forma más explicable— que pedirle

2026-07-16 原文 →
开发者

High-Cardinality File Access Analysis with Honeycomb + OTel

TL;DR We built a serverless pipeline that ships FSx for ONTAP audit logs to Honeycomb, where its high-cardinality query engine turns file access data into actionable insights. Two delivery paths verified: [Path A: Direct] FSx for ONTAP → S3 Access Point → EventBridge Scheduler → Lambda → Honeycomb Events Batch API [Path B: OTel Collector] FSx for ONTAP → S3 Access Point → EventBridge Scheduler → Lambda → OTel Collector → OTLP → Honeycomb Why Honeycomb for file access logs? Because file access data is inherently high-cardinality : thousands of users × millions of file paths × dozens of operations × multiple SVMs. Traditional log tools force you to pre-aggregate or sample. Honeycomb lets you query the raw events at full resolution. ┌──────────────────────────────────────────────────────┐ │ Honeycomb Query Engine │ │ │ │ "Show me which users accessed /vol/finance/* │ │ between 2am-4am last Tuesday" │ │ │ │ → BubbleUp: auto-detect anomalous dimensions │ │ → Heatmap: visualize access density over time │ │ → GROUP BY user, path, operation — no pre-indexing │ │ │ │ 20M events/month FREE │ └──────────────────────────────────────────────────────┘ This is Part 10 of the Serverless Observability for FSx for ONTAP series. Why Honeycomb for File Access Logs? Most observability tools index a fixed set of fields. When you have high-cardinality dimensions — like file paths ( /vol/data/project-alpha/2026/Q1/report-final-v3.docx ) or Active Directory usernames — you hit index bloat, slow queries, or forced sampling. Honeycomb's columnar storage handles this natively: Capability Traditional Logs Honeycomb Query by arbitrary field Pre-index or full scan Instant (columnar) GROUP BY high-cardinality field Expensive / limited Native BubbleUp (anomaly detection) Manual investigation Semi-automatic (select time range, BubbleUp identifies differing dimensions) Heatmap visualization Requires pre-aggregation Raw events For FSx for ONTAP audit logs, this means you can ask questions like: "Which

2026-05-31 原文 →