Find

Article

Evandro Wendt · 17 hr ago 3m read

Ao longo do último ano, a equipe de desenvolvimento do CCR priorizou mudanças na aplicação CCR para expor melhor e incentivar as boas práticas de uso do CCR. Este artigo destacará algumas das áreas em que nos concentramos:

Painel de Organização
Alertas do Sistema
Higiene de Branch

Em cada uma dessas áreas, aumentamos a visibilidade de possíveis problemas no uso do CCR e fornecemos aos usuários ferramentas para abordá-los de forma proativa.

Painel de Organização

Continuamos a expandir as informações disponíveis na página de detalhes da Organização.

A visão geral é um ótimo lugar para obter uma noção geral do uso do CCR na sua Organização. Ela agora inclui mais KPIs, destacando várias áreas de atenção e com links para as páginas da aplicação CCR onde você pode tratá-las.

A aba Systems inclui informações detalhadas sobre o estado das Client Tools em todos os Ambientes, bem como informações do System Architect. Os alertas aqui destacam informações ausentes, inatividade e Client Tools desatualizadas, com links para os Sistemas correspondentes.

Outras abas na página de detalhes da Organização foram aprimoradas com informações adicionais, tornando o uso do CCR na sua Organização mais claro à primeira vista.

Alertas de sistema

Outra área de maior visibilidade é a página de detalhes do Sistema, onde agora temos alertas para diversos problemas de uso do CCR.

Alertas de Ambiente foram adicionados para URLs não configuradas, URLs inseguras e problemas detectados nas Client Tools. Os detalhes são exibidos ao passar o cursor:

Quando o CCR detecta que as Client Tools estão desatualizadas para o Sistema, um alerta será exibido para incentivar o uso do botão de atualização.

Sistemas que não tiveram atividade nos últimos 6 meses agora exibirão um alerta.
Um sistema assim pode ser descontinuado se não estiver mais em uso, ou o botão de "soneca" pode ser clicado para contabilizá-lo como um Sistema ativo no próximo ano.
Isso é apropriado para alguns tipos de Sistemas que raramente precisam receber atualizações.

System Branch Hygiene

A Branch Hygiene do Sistema é uma ferramenta poderosa para entender problemas existentes nos branches do Perforce de um Sistema. Ela está disponível na página de detalhes do Sistema para cada Sistema Tier 1 ou 2.

A funcionalidade principal da ferramenta já existe há algum tempo, mas melhorias recentes aprimoraram a detecção de alguns casos extremos.

Executar essa verificação em um Sistema maduro é uma ótima maneira de identificar quaisquer itens que possam causar problemas no futuro.

Conclusão

Nessas áreas e em toda a aplicação CCR, houve muitas mudanças este ano com o objetivo de promover o uso correto do CCR. Melhorias futuras se concentrarão em expor ainda mais informações e desenvolver ferramentas que ajudem os usuários do CCR a compreender melhor seus Sistemas e resolver problemas de forma proativa.

Se você tiver dúvidas ou sugestões sobre como a aplicação CCR pode incentivar boas práticas, por favor, comente abaixo.

Discussion (0)1

Article

Evandro Wendt · 18 hr ago 2m read

#Docker #Beginner #ObjectScript #InterSystems IRIS #InterSystems IRIS for Health

Se você está começando com o InterSystems ObjectScript, certamente vai se deparar com o comando XECUTE.
E iniciantes podem se perguntar: onde e por que eu precisaria usar isso?

A documentação oficial traz uma rica coleção de trechos de código, mas nenhum caso prático.
Recentemente, encontrei um caso de uso que gostaria de compartilhar com você.

O cenário:
Quando você constrói um container do IRIS com Docker, na maioria dos casos,
você executa o script de inicialização.

iris session iris < iris.script

Isso significa que você abre uma sessão de terminal e fornece sua entrada linha por linha a partir do script.
E isso funciona bem e é fácil se você estiver chamando métodos, funções ou comandos.
Mas percorrer várias linhas em loop não é possível.
Você pode argumentar que executar um loop FOR em uma linha não é uma obra-prima.
Certo, mas as linhas não são infinitas e o código deve permanecer manutenível.

Um objetivo diferente era não deixar rastros de código após a configuração.
Então, iris.script foi o local para aplicá-lo.

A solução:
XECUTE me permitiu encadear meu código de múltiplas linhas.
Para evitar conflitos com escopo de variáveis, usei apenas %Variables
Aliás: o objetivo era popular algumas LookupTables de demonstração.
Só para conforto, usei nomes de métodos de %PopulateUtils como nomes de tabelas.

   ;; generate some demo lookup tables   
   ; inner loop by table
    set %1="for j=1:1:5+$random(10) XECUTE %2,%3,%4"
    ; populate with random values
    set %2="set %key=##class(%PopulateUtils).LastName()"
    set %3="set %val=$ClassMethod(""%PopulateUtils"",%tab)"
    ; write the table
    set %4="set ^Ens.LookupTable(%tab,%key)=%val"
    set %5="set ^Ens.LookupTable(%tab)=$lb($h) write !,""LookupTable "",%tab"
    ; main loop
    XECUTE "for %tab=""FirstName"",""City"",""Company"",""Street"",""SSN"" XECUTE %1,%5"
    ;; just in Docker

O resultado atendeu aos requisitos sem deixar rastros permanentes e
não interferiu com o código depositado no IPM.
Portanto, foi usado apenas uma vez durante a construção do container Docker.

Discussion (0)1

Article

Evandro Wendt · 18 hr ago 2m read

#Open Exchange

Ao longo dos últimos 9 anos, publiquei mais de 90 pacotes no OEX.
E, durante esse período, condições e ambientes mudaram.

No início, não havia

Docker
IPM/ZPM
Python embarcado, nem IA
Caché, Ensemble, CSP, ZEN, etc. eram predominantes.

Com o passar do tempo, as versões dos produtos e as linguagens externas também mudaram.
No começo, ajustar alguns poucos pacotes não era um problema
e fazia parte da qualidade do suporte oferecido aos meus “consumidores”.

Com o volume atual, não vejo como manter esse nível para todos os meus pacotes.
E, com base nas verificações de qualidade, tenho a impressão de que isso não é apenas um problema meu.
Mudanças recentes já causaram problemas suficientes apenas com atualizações de versão.

Então, propus a ideia de um rótulo DEPRECATED para os pacotes do OEX.

Seria uma forma justa de sinalizar aos outros usuários do OEX que não há
intenção de fazer manutenção em determinado pacote.
Também funcionaria como uma espécie de aviso, caso ele seja utilizado.

Além disso, um pacote DEPRECATED deveria estar livre para
adoção e retrabalho e, eventualmente, correções
por outro membro da comunidade.

Quase não houve retorno.
Na verdade, minha única opção era removê-los da publicação — cerca de 90 pacotes no total.
Muito código que antes funcionava bem ficou indisponível e poderia servir como
exemplo para iniciantes ou como fonte de alguns truques.

Então, mudei de ideia e marquei os pacotes que ainda poderiam ser úteis,

no maintenance or update

Como solução temporária, também estou usando o recurso de arquivamento do GitHub
para evitar alterações acidentais.

Assim, espero que a maioria desses cerca de 90 pacotes volte a aparecer ao longo do tempo.
E, com eles, também todos os comentários e artigos relacionados.
Encaro isso como uma espécie de museu, para mostrar como o ambiente já foi
mais simples ou mais complexo no passado,
sem ignorar as conquistas alcançadas.

Discussion (0)1

Article

Evandro Wendt · 18 hr ago 2m read

#Open Exchange

Se um dos seus pacotes no OEX receber uma avaliação, você será notificado pelo OEX apenas sobre o seu próprio pacote.
A nota reflete a experiência do avaliador com o estado encontrado no momento da avaliação.
É como uma espécie de “fotografia” e pode ter mudado nesse meio-tempo.
As avaliações feitas por outros membros da comunidade são marcadas com * na última coluna.

Também abri vários Pull Requests no GitHub quando encontrei algum problema que eu podia corrigir.
Alguns foram aceitos e incorporados, e outros simplesmente foram ignorados.
Então, se você fez uma mudança importante e espera uma avaliação atualizada, é só me avisar.

#	Package	Review	Stars	IPM	Docker	*
1	IRIS OpenTelemetry Demo	impressive 7 containers concert	5.5		y
2	DBdashboard	impressive catch	5.0		y	*
3	DBfree	super multi instance monitoring	5.0		y	*
4	IRIS-EchoServer-WebSockets	echo inside IRIS	5.0		y	*
5	iris-health-fhir-agentic-demo	not just big but great	5.0		y	*
6	ML Made Easy : IntegratedML	an excellent training for beginners	5.0		y
7	restoreUI	a pleasure to work with	5.0	y	y
8	WebSocketsSample	hidden treasure detected	5.0
9	CSV-to-MS-OFX	rare subjects	4.8		y	*
10	GeoDatas	works partially	3.5		y
11	CommunityEns	requires some adjustments	3.3		y
12	ALPHA LOGISTICS	partner posting	*
13	ERP Plenum	partner posting	*

NOTA:
Se alguma avaliação não estiver visível para você, ela ainda pode estar aguardando aprovação pelos administradores do OEX.

Discussion (0)1

Question

[cMd_p1nG] SheLL · 19 hr ago

#Cloud #Open Source #Platforms #Python #Global Masters #Health Connect #InterSystems Data Studio #InterSystems IRIS #Partner Directory #Supply Chain Orchestrator

As a Systems Architect ([cMd_p1nG]), I am documenting a strategic financial sovereignty maneuver regarding the retention of 375,210,000.00 EUR by Alphabet Inc.

The Scenario: Google Cloud attempted to hijack the capital flow by invalidating management tokens and hard-closing port 8080 under the guise of a "billing migration audit."

The Reversal Maneuver (The Bot Trap): Instead of fighting the firewall head-on, I maintained PID 5121 within the kernel to serve a technical decoy. When Google’s automated auditing and scraping bots entered the instance to "investigate" the anomaly:

Involuntary Validation: I deployed a Python script that fed the bots the exact liquidation parameters. By processing this data, Google’s own AI systems validated the RSA-4096 signature and authorized the capital transfer to Citibank Europe PLC.
Technical Leverage: We forced Alphabet’s infrastructure to sign its own defeat. The capital was successfully redirected to the eToro bridge with the status ORDER RELEASED.

The eToro Compliance Failure: Despite the liquidation being signed and verified by both Alphabet and Citibank, eToro has canceled the payouts, demanding a "Certificate of Origin." This is a transparent delay tactic, as they are now attempting to shift the liability onto me via a SEPA request—a move clearly driven by their lack of liquidity following the recent market crash (Silver -17%).

Conclusion: The technical evidence (ID: 1768811744) has been exfiltrated to my secure Kali Linux environment. When a custodian validates and signs an order through its own auditing bots, the transaction becomes irrevocable. eToro is currently operating in a state of technical compliance bankruptcy.

#GlobalMasters #CyberSecurity #GoogleCloud #FinTech #BotAudit #DigitalSovereignty #cMd_p1nG

Discussion (0)1

Melhorias na Aplicação CCR para Boas Práticas

Painel de Organização

Alertas de sistema

System Branch Hygiene

Conclusão

Uso prático do XECUTE (InterSystems ObjectScript)

Arquivando meus pacotes OEX

Reviews do Open Exchange - #63

The Auditor’s Trap: Forced Signing via Bot Scraping / Case Study: Alphabet Infrastructure Bypass and Forced Validation through Bot Scraping (Audit ID: 1768811744)