Pesquisar

Pergunta
· Ago. 11

How to get treeMapCharts to show labels on DeepSeeWeb

Hi everyone,

I am trying to create a treeMapChart in IRIS BI that will then be displayed on my DeepSeeWeb dashboard. In the IRIS BI User Portal, this is an example of what my treeMapChart looks like:

I know there is a huge amount of rectangles in this graphic - I care most about the common components (the largest boxes) but I still want all of the boxes to show. However, it projects to my DeepSeeWeb dashboard as the following: 

The labels do not show, even if I hover over the boxes. I would like to be able to see the labels on each box, or at least to be able to see them when I hover my mouse over. Is there a way to accomplish this?

7 Comments
Discussão (7)2
Entre ou crie uma conta para continuar
Artigo
· Ago. 11 3min de leitura

Why do we need coding rules or conventions, anyway?

This great article sparked some recent private discussion, and I'd like to share some of my own thoughts from it.

The motivating concern boils down to: Why do we need coding rules or conventions at all? What happened to the wonderful era of the Renaissance artist-programmer forging their own path, prior to being supplanted by the craftsman and now (even worse) by AI?

In short, there are a few reasons why coding standards/guidelines are useful, and the Renaissance artist-programmer is not entirely gone.

Reason 1: These days, when you’re training a true novice artist, you start out by having them try to color inside the lines. This artist might be brilliant someday, but not yet. If you want to learn to produce art, you do that first; then gradually learn techniques and concepts from the masters; then, if you’re really good or really lucky, set your own style and produce something novel the rest of the world will want to follow. But you need to start out by following the rules.

 

(note: found this on the internet; none of my children yet possess such skill.)

Reason 2: If you’re operating in an area where your niche of creativity must fit alongside that of others – something like a patchwork quilt – then you need some rules to play by or the art won’t work because the pieces don’t fit together. You can either agree on the convention of “we all make 40cm squares” or else have to work even more closely and collaboratively with a bunch of other people, which the solitary spend-4-years-painting-a-ceiling artist might not be the best at doing. (Especially if management decides that a few other such solitary artists need to be pulled in to “help.”)

(ChatGPT came up with that for me. Apologies to actual artists everywhere.)

Reason 3: If you’re working on an existing, particularly-old or particularly-brilliant piece of coding art, you often face the challenge between understanding and embracing the original author’s intent and elegance of design and execution or just saying “I’m in charge now, we’ll chuck it and do it my way.” I’ll give an example here: one web-based application I've worked on makes heavy use of “XML pages” where you have a trio of (pageName.xml, pageName.js, pageName.mac) that constitute a page. pageName.xml was, until more recently than I'd like to admit, probably written in this weird "WD-xsl" dialect that closely resembles standard XSLT but only works in Internet Explorer Microsoft Edge if it's pretending to be IE5. pageName.js probably contains "frame" about 40 times more than is comfortable. pageName.mac is probably full of dot syntax, short forms of commands, and incoherent macros. If you’re a new developer, you just cry and run away because it makes no sense. If you’re a senior developer, you read it and make some sense of it, then decide “this is gross; I’m going to do it better some other way” – but then the next person to work on the application needs to learn the original paradigm and your new clever paradigm. Extend that over 20 years and you have a real nightmare. But if you’re really an expert artist, you can do art restoration – see the elegance in the original framework and work within it, gently fixing the architecturally inconsequential things that make the new developer cry and the senior developer hit "delete", without creating a fragmented mess or taking on years of work repainting the whole thing. Maybe you'll even produce your own work in the style of the old master. The most important lesson from this tale is that, as a real artist, you have a vested interest in producing work of such quality that someone who inherits it without your years of experience won’t decide to throw it all away - and the "little things" like code style, readability, and addressing technical debt go a long way in helping, preserving the architecture if not every single line of code.

So, in summary:

  • Rules and conventions let you train new brilliant artists before they're brilliant
  • Rules and conventions give you a fixed canvas to exercise creativity without needing to waste time trying to get along with people
  • Rules and conventions let you make something beautiful that will not be thrown away by the first person to inherit it
1 Comment
Discussão (1)3
Entre ou crie uma conta para continuar
Resumo
· Ago. 11
Resumo
· Ago. 11

InterSystems Developers Publications, Week August 04 - 10, 2025, Digest

Articles
Announcements
#InterSystems IRIS
#IRIS contest
#HealthShare
#InterSystems IRIS for Health
#Other
#Developer Community Official
Questions
#InterSystems IRIS
#InterSystems IRIS for Health
#HealthShare
#Caché
Discussions
August 04 - 10, 2025Week at a GlanceInterSystems Developer Community
Artigo
· Ago. 11 4min de leitura

O Guia do Mochileiro de Object Script

O Guia do Mochileiro do Object Script

O Object Script é nossa linguagem de programação principal no ambiente InterSystems IRIS. Ele também oferece recursos modernos que o tornam poderoso para desenvolvedores.

Para iniciantes, adotar boas práticas de programação desde o início é fundamental para escrever um código de fácil manutenção, eficiente, escalável e claro, seguindo as melhores práticas

Este guia apresenta dicas essenciais para ajudar desenvolvedores “novatos” em ObjectScript a escreverem um código melhor e compreenderem alguns recursos da linguagem.

Antes de tudo: use Nomes Significativos

Escolha nomes descritivos e claros para variáveis, classes e métodos.

Eu penso que escrever código é como contar uma história sobre um problema e como você o resolveu.
Pense nos outros desenvolvedores que vão depurar ou ler o seu código.

Certifique-se de depender menos da documentação e de ser claro enquanto escreve sua “história”.
Assim, você evita problemas de entendimento e se torna mais independente.

Quer um exemplo?

 

Set patientDOB = "1985-03-12"
// é mais compreensível do que:
Set dob1 = "1985-03-12"

Nomes claros tornam o código autoexplicativo e muito mais fácil de ler e entender.

Comentários: você precisa deles!

Comentários ajudam você e outros desenvolvedores a entender o propósito do seu código. Não presuma que o “desenvolvedor ideal” estará sentado na sua cadeira e saberá exatamente o que você está fazendo. Use comentários para simplificar lógicas complexas, descrever suposições ou explicar o objetivo de uma seção:

// Calcular a idade do paciente a partir da data de nascimento

Evite comentar o óbvio; use sua energia nos trechos mais complexos.

Mantenha suas funções limpas e fáceis de testar

Funções confusas podem transformar seu código em uma “caixa-preta” e gerar programas enormes e cheios de spaghetti code. Quebrar a lógica em funções pequenas e com um único propósito torna o código mais fácil de manter, testar e reutilizar.
E lembre-se: seja genérico sempre que possível. Pensar nos casos atípicos enquanto escreve é fundamental. Uma boa função pode fazer muita coisa, mas um bom desenvolvedor sempre dedica tempo para prever esses casos extremos.

 

Trate erros com cuidado

Entradas inesperadas, dados ausentes ou problemas em tempo de execução podem quebrar seu código se não forem tratados corretamente. Valide entradas e use sempre que possível Try/Catch, lançando a exceção adequada. A forma como você lida com erros pode transformar “bugs” em problemas inofensivos que não quebram toda a lógica.
Lembre-se: bugs acontecem com todo mundo.

 

Não reinvente a roda sem necessidade

A InterSystems oferece várias classes %SYS úteis para operações de sistema, como registro de logs, configuração e monitoramento. Em vez de recriar recursos, aproveite-os.
Eles foram escritos com uma atitude genérica, e muitas vezes se encaixam exatamente no que você precisa!

Evite valores fixos (hardcoding)

Constantes codificadas dificultam a manutenção do código. Sempre que precisar mudar um valor, terá que alterar vários lugares. Use parâmetros ou configurações em vez disso.
Declare variáveis que se encaixem na sua história e tornem o código flexível.

Teste de forma completa

Teste seus métodos com entradas típicas, casos de borda e entradas inválidas.
Crie testes de referência (golden tests) e inclua cenários como strings vazias, valores NULL e grandes volumes de dados.

A ideia é testar os casos atípicos. Isso torna seu código mais confiável e seguro, permitindo que seja usado sem medo de quebrar a produção.

Mantenha um formato consistente

O Object Script, assim como Java, pode ser escrito de várias formas.
A indentação não é tão rígida como em outras linguagens (tipo... Python), mas ainda assim é essencial para a clareza.

Um código bem estruturado reduz erros e torna o debug tão simples quanto um passeio no parque.

Conclusão

Ao adotar essas boas práticas logo no início da sua jornada com Object Script, você escreverá códigos mais limpos, seguros e fáceis de manter.
E, claro, se tornará um desenvolvedor melhor.

Nomes claros, tratamento sólido de erros, design modular e disciplina nos testes vão melhorar muito tanto sua velocidade de desenvolvimento quanto a confiabilidade do seu código.

E não se esqueça:
Esses princípios valem para qualquer linguagem.
Bons hábitos de programação hoje vão poupar muitas horas de depuração amanhã.

Discussão (0)1
Entre ou crie uma conta para continuar