| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | Sim... (Pontos:5, Interessante) |
| | | Alguém tem mais algum erro para adicionar à lista? Yep -- Project Wars.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| | | | | | Leitão, acho que pela primeira vez vais levar com um comentário positivo.
Muito bom artigo :)
SINCLAIR ZX SPECTRUM+2
128K RAM
COMBO TAPE READER/RECORDER ONBOARD
CRT 12" WITH SPEAKER |
| | | | interessante
Santana Claus... |
| | | | Onde se lê "How long will this task to complete, assuming a best, ...", deveria ler-se "How long will this task TAKE to complete, assuming a best, ..." ?
Bom artigo, gostei especialmente da parte que me lembrou do famoso PDCA (Plan, Do, Check, Act/Adjust ;)
-- pmsac.oO(Cogito sumere potum alterum) |
| | | | Erro número 11! - Importantissimo
"You should never underestimate the predictability of stupidity" - Bullet Tooth Tony |
| | | | Em sequência do "KISS" há outra epígrafe que costumo tentar por em prática - "don't fix what isn't broken".
Uma outra coisa que normalmente vejo desprezada é o factor de erro. Por mais cuidado que seja o planeamento de um determinado projecto, normalmente deixa-se de fora a hipótese de erro não calculado, ou seja, quando as coisas correm mal independentemente de todos os cuidados que se tomaram. Esse tipo de erros é comum em projectos de software, normalmente consequência de estratégias de programação pela positiva (assume-se que na generalidade as operações executadas são executadas correctamente, e o trap de erros é mínimo), e em hardware/networking costuma ser por excesso de confiança - como em muitos casos são configurações já extensamente testadas, assume-se que são fiáveis. A verdade é que, "quando uma coisa poder correr mal, correrá mal". Normalmente nas implementações sob minha responsabilidade tento sempre ponderar um factor de erro não controlável, e delinear sempre estratégias alternativas, se não para todos os componentes, pelo menos para os componentes mais críticos. Normalmente evita-me derrapagens em prazos estabelecidos e em custos para os clientes, além de eventualmente aumentar a confiança do cliente precisamente nas situações de falha. Admito que seja um bocado paranóico, mas tem funcionado :)
|
| | | | | | | Em sequência do "KISS" há outra epígrafe que costumo tentar por em prática - "don't fix what isn't broken". Isto por si so' e' muitas vezes um erro. Muitas vezes so' porque "it isn't broken" nao quer dizer que nao va' estar. Frequentemente uma mudanca de estrategia vai originar quebras no design, e uma analise atempada pode identificar areas que se devem mudar em nome da flexibilidade futura.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| | | | A substituição (muitas vezes inconsequente) de sistemas estáveis e em produção já há vários anos, por mudança de estratégia, é em muitos casos, um erro, além de aumentar a provabilidade de falha do sistema como um todo. As alterações, por mais ínfimas que sejam, podem ter resultados que põe em causa a tal mudança de estatégia. Por exemplo, em software, se uma empresa possui uma aplicação "legacy" que corresponde às necessidades da empresa, em muitos casos é um erro mudar para um novo sistema, mais recente, e sem todo o tempo de teste do sistema antigo. Um belo exemplo disso é a esmagadora maioria do software usado no sector financeiro. Ainda são raras as instituições que não possuem o "core" a correr em Cobol ou RPG. Por outro lado, se se pretende mudar o que está implementado por uma questão de estratégia, também é pertinente questionar a própria estratégia em si. A implementação que se pretende mudar também foi fruto de uma estratégia, que se demonstrou válida durante o tempo de vida da solução. Que garantias se obtém das mais-valias dessa flexibilidade futura? Que protecção se obtém dos investimentos feitos quando o que está em causa é o bom-funcionamento de uma instituição?
|
| | | | | Sim claro -- mas repara que o modelo bancario nao mudou muito nos ultimos 30 anos. Mas quando se fala de empresas onde a mudanca e' constante, uma atitude de "if it ain't broke don't fix it" pode simplesmente impedir a adopcao de modelos (tecnologicos ou de negocio) que incitem a mudanca para o melhor, e que abra as portas a novas formas de fazer as coisas. Vou-me candidatar a cairem-me os 4GR's e CrLf's deste mundo, mas as empresas tecnologicas mais bem sucedidas (Microsoft, Apple, IBM, etc.) sao aqueles que souberam manter um ciclo de inovacao atravez da mudanca constante da estrategia e dos produtos.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| | | | Vou-me candidatar a cairem-me os 4GR's e CrLf's deste mundo, mas as empresas tecnologicas mais bem sucedidas (Microsoft, Apple, IBM, etc.) sao aqueles que souberam manter um ciclo de inovacao atravez da mudanca constante da estrategia e dos produtos.
Lamento desapontar-te, mas aqui concordo contigo. Eu não digo que os produtos da Microsoft (o teu exemplo provocante) não tenham evoluído ou sofrido inovações, apenas digo que a prática corrente é a Microsoft copiar a inovação de alguém ou simplesmente adquirir esse alguém).
--
Carlos Rodrigues
|
| | | | Algumas vezes nem é preciso realmente evoluir... basta dizê-lo com muita convicção e dinheiro que a ideia que fica é que houve evolução.
É assim como a história da baixa do IRS se este orçamento fosse aprovado: o imposto não baixaria... mas tantas vezes foi dito que sim, que ficou a ideia que o governo era nosso amigo e até baixava o imposto.
~~~ O vinho é q'induca e o fado é q'instrói ~~~ |
| | | | É assim como a história da baixa do IRS se este orçamento fosse aprovado: o imposto não baixaria... mas tantas vezes foi dito que sim, que ficou a ideia que o governo era nosso amigo e até baixava o imposto.
O que interessa é que significa para ti, isto é, é por isso que tens cérebro, é para o utilizares, os outros hão-de dizer sempre muita coisa e todos têm muita coisa a dizer, mas para mim o importante é o que eu acho...
My son is now an "entrepreneur." That's what you're called when you don't have a job.
Ted Turner |
| | | | Sim, é verdade. Talvez devesse ter sido mais específico na área a que me referia. O meu comentário não era sobre empresas cuja área de mercado seja essencialmente o desenvolvimento de produtos, onde inovação e a competitividade tecnológica são elementos chave, mas sim no sector de serviços. Mas mesmo na Microsoft encontramos exemplos, como a utilização da tecnologia NT nas versões mais recentes dos SO's. O mesmo se passa na Apple (o OS X é baseado em tecnologia já com provas dadas) e na IBM (ainda o OS/2, os mainframes e o RPG).
|
| | | | Este é daqueles temas que daria pano para mangas, e então ter o campo aberto para generalizar é fantástico, mas já agora gostava de deixar aqui alguns comentários meus para discussão.
O teu racioccionio está correcto, mas a área de serviços como é baseado em pessoas traz grandes problemas, tipo:
1- Nem sempre o cliente vai aceitar ser ele a pagar o risco que basicamente é o que procuras fazer (e como não deves ser muito "paranóico" e os projectos têm corrido bem os clientes têm aceite, este é um factor que aumenta a tua competitividade)
2- Em cenários de grande competitividade vais (e dependendo do que estiver em causa) ter tendência a minimizar este seguro para te manteres efectivamente competitivo
3- Depois numa questão paralela, quanto te tornares um fornecedor confiável e preferencial, podes ter a tendência de fazer mais do que seria necessário (não fazer o que faz sentido do ponto de vista do cliente mas no teu) principalmente
se as condições de mercado estiverem dificeis
Comentários?
My son is now an "entrepreneur." That's what you're called when you don't have a job.
Ted Turner |
| | | | | 1- Nem sempre o cliente vai aceitar ser ele a pagar o risco que basicamente é o que procuras fazer (e como não deves ser muito "paranóico" e os projectos têm corrido bem os clientes têm aceite, este é um factor que aumenta a tua competitividade) 2- Em cenários de grande competitividade vais (e dependendo do que estiver em causa) ter tendência a minimizar este seguro para te manteres efectivamente competitivo Tens toda a razão, mas por outro lado a fiabilidade é um nicho de mercado. Não é toda a gente que está disposta a pagar mais por qualidade, principalmente em contextos em que quem toma as decisões nada tem que ver com o sector das TI, o que diminui a aceitabilidade dos serviços prestados. Não obstante, isso também é uma mais-valia, porque o grau de satisfação do cliente é maior e a fidelização ocorre mais facilmente, o que, a meu ver, acaba por compensar a médio prazo. 3- Depois numa questão paralela, quanto te tornares um fornecedor confiável e preferencial, podes ter a tendência de fazer mais do que seria necessário (não fazer o que faz sentido do ponto de vista do cliente mas no teu) principalmente se as condições de mercado estiverem dificeis Eu não me comprometo com coisas que não posso assumir. Não posso assegurar fiabilidade de produtos ou soluções que não testei ou que não tenho a certeza de conseguir viabilizar. Poderei, é certo, usar clientes como "cobaias", mas nunca sem eles terem perfeita noção que estão a ser parte de um teste de campo, partilhando os riscos e os custos.
|
| | | | Não é toda a gente que está disposta a pagar mais por qualidade
Está, está, esses gestores compram bem a paz de espirito como todos nós, mas a experiência leva-os a desconfiar... infelizmente este mercado tem um passado e porque não dizer presente onde o que sobressai é a falta de qualidade, e isso não ajuda, a credibilizá-lo.
Estás certo na tua prática, mas estás porventura numa escala pequena, os problemas a que me referi começam a aparecer quando já tens uma estrutura e meios com algum peso... ;o)
My son is now an "entrepreneur." That's what you're called when you don't have a job.
Ted Turner |
| | | | Underestimating PHP parece ter sido um ponto dedicado a elucidar pessoas ditas do "mundo TI", como por exemplo o Leitão, que talvez por não terem tido nos projectos deles um contacto directo com tecnologias como o PHP, usam outras coisas porque na verdade parecem não conhecer mais do que isso.
Essa foi a impressão que o Leitão deixou em discussões passadas ao argumentar que "O PHP já esta' derrubado -- a Microsoft nem precisa tentar."
Isso foi no ano passado. Quem sabe desde então ele já tenha tomado melhor ciência do "real world" como ele gosta de dizer quando está a tentar demonstrar a "superioridade" dos seus conhecimentos. ;-)
|
| | | | | | Eh pá, eu gosto muito de PHP, mas para aplicações cuja continuidade se espera que dure vários anos, ou até uma década, o PHP não oferece garantias nenhumas. De versão para versão muda alguma coisa que quebra a compatibilidade com versões anteriores, ou até muda a abordagem da própria linguagem. É normal que linguagens cuja estrutura básica seja estável tenham mais capacidade de penetração em ambiente empresarial.
|
| | | | Se pensares nas mudanças de abordagem que a Microsoft introduziu com a plataforma .Net, talvez chegues à conclusão que o teu argumento sobre a capacidade de penetração em ambiente empresarial das linguagens que mudam talvez não tenha muita razão de ser.
De qualquer modo, penso que no mundo do PHP até existe uma grande preocupação com a manuntenção da compatibilidade com versões. O que acontece é que algumas mudanças foram feitas para obter benefícios e o modo de manutenção compatibilidade com versões requer ajustes na configuração do PHP que os menos atentos podem não se aperceber logo da necessidade desses ajustes.
|
| | | | | Se pegares numa aplicação feita em VB em 1998, consegues convertê-la automaticamente e com um bocado de sorte/alterações mínimas compilá-la em VB.NET hoje. No caso do php, um script feito para php 4.0 poderá não correr no php 4.3, e em muitos casos obrigando a alterações manuais no código. Não chateia muito se forem umas dezenas de Kb, mas se forem uns milhares de Kb, a coisa já complica. Para um exemplo completamente diferente, na altura do ano 2000 eu programava em Cobol numa empresa de software. Uma das aplicações tinha código de 1982/83 misturado com código mais recente, num total de mais de 300Mb de source. A modificação para assegurar a recompilação em Windows implicaria um trabalho monstruoso - felizmente não foi preciso. O compilador existente para Windows compilou perfeitamente o código com (quase) 20 anos. Em termos do código em si, estava feito em 3 revisões da linguagem, e não deu bronca nenhuma. Esse tipo de compatibilidade tem sido difícil de encontrar com o PHP. Talvez com a v5 as coisas melhorem, mas existe uma tonelada de código para a v4 que não está assegurado que corra na v5. Não obstante, php é um vício, que satisfaço pontualmente :)
|
| | | | O que te estava a tentar dizer talvez de uma forma não muito explícita é que o problema que encontraste entre PHP 4.0 ou 4.3 poderia talvez ser resolvido pondo a opção register_globals=On no php.ini e nem sequer terias de mexer no código. Não foi o PHP em si que mudou mas mas sim o valor inicial dessa opção.
|
| | | | A questão do register_globals está directamente relacionada com a abordagem da linguagem. Inicialmente era fomentado um determinado tipo de abordagem a um problema, hoje em dia é fomentado outro que é incompatível com o anterior. A mudança de register_globals, por si, não é solução, até porque existem alterações nos parâmetros de algumas funções. Por essa ordem de ideias, porque é que não se fez desde o início o código compatível com register_globals=Off, que até era recomendado, não só por questão de bom funcionamento do código, mas por questões de segurança?
|
| | | | Este ponto nunca foi bem esclarecido. O que é preciso que entendas é que o PHP em si não mudou. O que mudou foi o valor inical de uma opção.
A verdade é que não existe nenhum problema de segurança que possa ser evitado usando register_globals=On . Nos meus sites eu sempre uso essa opção assim.
O problema é que muitos programadores não têem muita experiência e acabam por usar as variáveis globais de forma errada. Estavam a surgir alertas de vulnerabilidades de aplicações de PHP que na verdade não eram um problema do PHP em si.
A mudança do valor inicial desse opção serviu para de certa forma coagir os programadores menos experientes a escrever código PHP sem esses problemas de segurança.
Agora isso não te impede de mudares o teu ficheiro php.ini e por register_globals On em aplicações que precisem disso.
|
| | | | | A verdade é que não existe nenhum problema de segurança que possa ser evitado usando register_globals=On. Presumo que te referisses a register_globals=Off. Na realidade, mesmo em código correctamente implementado, o facto de todas as variáveis passadas ao script serem automaticamente de âmbito global permite por vezes mudar valores de variáveis que não estão correctamente inicializadas, além do impacto de performance. Se a própria equipa do php recomenda register_globals=Off por questões de segurança, não percebo em que te baseias para afirmar tal coisa. Mais, activar register_globals em código bem feito, é aumentar a vulnerabilidade do script, porque eventualmente se expõe bugs que dificilmente ocorreriam com a flag desactivada. Os programadores são pessoas, e as pessoas erram. Exemplo disso é a quantidade de software em PHP que tem ou já teve incidentes relacionados com a activação do register_globals. São todos incompetentes? A mudança do valor inicial desse opção serviu para de certa forma coagir os programadores menos experientes a escrever código PHP sem esses problemas de segurança. Todo o código tem falhas. Algumas são facilmente identificáveis até com ferramentas automáticas, outras não. Em projectos grandes (por acaso nunca vi nada com mais de 20Mb de source em php), com várias pessoas a desenvolver, e mais tarde até outras pessoas a manter, o factor de falha imprevisível aumenta exponencialmente. Ocorrem situações em que um dado programador corrige um problema de âmbito local sem analisar as implicações globais no resto do código. Este tipo de falha, inerente a qualquer projecto de desenvolvimento, não é facilmente evitável. No caso do php, o evitar que as variáveis sejam automaticamente de ambito global pode prevenir situações de erro e aumentar a segurança global da aplicação. Agora isso não te impede de mudares o teu ficheiro php.ini e por register_globals On em aplicações que precisem disso. Em aplicações web, o ideal é até meter isso no .htaccess.
|
| | | | Não é verdade que a equipa do PHP toda concordo em mudar a opção do register_globals. O próprio autor original do PHP, Rasmus Lerdorf discordou disso precisamente pelos transtornos que causou que levaram muitos a acreditar que a compatibilidade com versões passadas foi quebradas.
Por outro lado, não registar os valores do acesso HTTP como variáveis globais também não vêm daí nenhum mal ao mundo.
Esta opção foi introduzida para cobrir uma situação hipotética que pessoalmente não vi em nenhum relatório de vulnerabilidades de aplicações de PHP. Não digo que não ocorra, mas acredito que quem tem problemas derivados disso não seja muito experiente em PHP.
As vulnerabilidades mais comuns são de cross-site scripting e SQL injection, mas isso acontece com aplicações em praticamente todas as linguagens usadas para aplicações Web. Agora ninguém disse que por existirem aplicações com bugs que os programadores são necessariamente incompetentes.
Felizmente, certas aplicações de PHP já são tão populares que muitas são sujeitas a auditorias imediatas por grupos independentes depois do lançamento de novas versões. Isso até faz parece com que *Nuke, phpbb, etc.. pareçam muito mais fracos do que outros projectos menos populares.
|
| | | | Se pegares numa aplicação feita em VB em 1998, consegues convertê-la automaticamente e com um bocado de sorte/alterações mínimas compilá-la em VB.NET hoje.
Eu recomendo que ponderes bem sobre esta frase, sabendo que há por aí muito boa gente a migrar aplicações VB6 para VB.NET, o que significa que não é só click 'n' go.
--
Carlos Rodrigues
|
| | | | | há por aí muito boa gente a migrar aplicações VB6 para VB.NET Há por aí muito boa gente a fazer quase tudo o que se pode imaginar :)
Embora a migração para o VB.NET não seja pacífica na esmagadora maioria dos casos, as ferramentas automáticas dão uma ajuda preciosa, e estima-se que cerca de 90% do código seja convertido sem problemas. Nos casos em que obriga a intervenção do programador, normalmente são inseridos comentários a sugerir o tipo de alteração. Ora, com aplicações com mais de 200 formulários, convenhamos que o trabalho resultante é uma fracção do necessário. Agora ponderemos, por exemplo, a conversão de 200 scripts PHP para funcionar com register_globals desactivado. Conheces alguma ferramenta que te faça 90% do trabalho? Eu não. O VB também tem outro problema... Potencia a má programação. De facto, conheço muito poucas pessoas que sabem programar em VB. A maioria do código que vejo é código à pedreiro, feito por pessoas que deviam ser proibidas de tocar em computadores. Posso ser eu que realmente tenho azar com o código e com as pessoas, mas a impressão que tenho é que há mais maus programadores em VB do que bons. Em VB existe um parâmetro (option explicit, salvo erro) que obriga a que todas as variáveis sejam declaradas, o que evita toneladas de erros aquando a utilização de variáveis locais já definidas em âmbito global. Não obstante, nunca vi ninguém usar isso :P
|
| | | | Epa... não me lixem... tenho um site minúsculo onde uso PHP... e quando quero meter uma versão nova (até por questões de segurança) arrisco-me a ter de refazer coisas.
Agora por exemplo, estou a trocar de máquina... ao recompilar o PHP (porque preciso de coisas "esquisitas") tive alguns problemas e deparei-me com o seguinte: Na versão 5 uma extensão que uso vai simplesmente desaparecer... Se isto fosse um site grande ia ser uma dôr de cabeça...
Apesar da pouca experiência, julgo que o PHP é dos melhores exemplos de um dos defeitos do OSS: não se preocupam grandemente com retro-compatibilidade...
Cumprimentos.
|
| | | | "julgo que o PHP é dos melhores exemplos de um dos defeitos do OSS: não se preocupam grandemente com retro-compatibilidade"
Por acaso tens dados que funtamentem esta afirmação ou foi só um desabafo?
É que OSS não é só PHP.
Quanto ao PHP... não gosto e por isso não como. Não tem nada a ver com o facto de ser OSS ou não.
~~~ O vinho é q'induca e o fado é q'instrói ~~~ |
| | | | Já senti isso com a libc e com threads no Linux... Já li discussões em que se afirma algo como: " o progresso não se compadece com manter código antigo ".
Conceptualmente até é porreiro ser o "progresso" a mover as coisas, mas quando mexes numa coisinha e estragas duas ou três torna-se muito chato... O equilíbrio será um ideal. A meu ver o PHP está longe do ideal...
Já agora, eu não sou o tipo indicado para discutir estas coisas... falta de experiência. De qualquer forma estas são as sensações que tenho (baseadas em algumas situações porque passei).
Cumprimentos.
|
| | | | Pessoalmente não recomendaria o uso de PHP 5 ou de qualquer programa lançado há pouco tempo porque só agora está a ser testado em grandes bases de código e os bugs mais subtis vão continuar a surgir.
De qualquer modo, essa extensão não será por acaso uma daquelas que foi mudada para o PECL?
O que se passa é que o PHP já tem demasiadas extensões para distribuir com o a base do PHP. Por isso começaram a determinar quais as extensões menos importante e mudaram para o PECL. Isso não te impede de as instalares quando quiseres. Apenas tens de fazer o download e instalação de forma separada.
|
| | | | Acho que sim... teria de verificar, mas lembro-me de ver isso na página. Desculpem a falta de exactidão, mas foi algo que referi porque "passei os olhos" por lá. De momento não estou minimamente preocupado com o PHP 5.
Mas já tive outros exemplos. O comportamento das variáveis é conhecido. Não estou preparado para o discutir, mas tenho ideia que tive de alterar código à conta disso e eu conheço o php.ini...
Mas já agora, não escolhi o PHP ao acaso... é muito fácil e tem "tudo"... E estas duas coisas agradam-me muito.
Cumprimentos.
|
| | | | Eh pá, eu gosto muito de PHP, mas para aplicações cuja continuidade se espera que dure vários anos, ou até uma década, o PHP não oferece garantias nenhumas. Podes manter a mesma versão do PHP ad aeternum, mesmo mudando bibliotecas base.
Pode ser eventualmente necessário alterar um pouco o código fonte para permitir compilar em novos ambientes, mas é de bem mais longa duração que qualquer coisa produzida pela Microsoft até hoje. Nunca serás forçado a migrar pela mera falta de suporte do fornecedor.
Case in point, o Linux série 2.0.x ainda continua a ser mantido. O 2.0.0 saiu quando? E os Windows 9x, ainda são mantidos? :)
|
| | | | | E os Windows 9x, ainda são mantidos? O Windows 98? Sim, embora a Microsoft tenha feito um esforço para desistir do suporte a esse SO. Foram pressionados e voltaram atrás na decisão. Penso que a nova estratégia deles é implementar o Windows XP com menos programas, cujo custo é muito inferior ao preço do W XP normal, de modo a que quem usava W 98 tenha hipótese de passar para W XP. Quanto ao Windows 95, não sei!
|
| | | | | Isso foi no ano passado. Quem sabe desde então ele já tenha tomado melhor ciência do "real world" como ele gosta de dizer quando está a tentar demonstrar a "superioridade" dos seus conhecimentos. ;-) O que o "real world" me diz e' que tu criaste e mantens o PHPClasses. Como tal nao me parece seres uma classe desinteressada para mandares comentarios sobre a aplicabilidade desta ou daquela linguagem.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| | | | O mesmo se poderia dizer sempre que criticas o Apache e aplaudes o Zeus. Tal não significa que o PHP, tal como o Apache, não estejam por aí a ser usados com sucesso em situações onde os gurus como tu não lhe reconhecem capacidades.
--
Carlos Rodrigues
|
| | | | Claro, mas repara que não fui eu que escrevi o artigo a dizer que é um erro substimar o PHP, que era o que estavas a fazer na outra discussão.
Cometer erros é humano, mas insistir neles depois de tantas fontes explicarem isso já me parece ser burrice. A questão era saber se ainda estás a insistir neste erro depois disto.
|
| | | | | The stateless “shared-nothing” architecture of PHP means that each request is handled independently of all others, and simple horizontal scaling means adding more boxes. . O sucesso da utilização das linguagens de scripting como o PHP, Perl, etc depende em larga medida na complexidade do que se quer fazer. Acredito que é mais facil e rápido criar o site da empresa ali da esquina em PHP, Perl, etc do quem em .NET ou J2EE. Mas por outro lado se estivermos diante de algo mais complexo, como por exemplo um site de eCommerce, que possui uma natureza transacional, o .NET ou J2EE são uma solução mais robusta eadequada. Não digo que não se possa fazer em PHP, Perl, etc mas se comparamos o tempo de desenvolvimento, o custo de manutenção e de futuros desenvolvimentos será que vale a pena ??
___________________________________ (linooks (at) zmail (dot) pt) |
| |
|
