Pesquisar neste blogue

domingo, 16 de abril de 2017

Extractores de humidade (Comparativo 2017)

De forma a ver que extractores existem de melhor em termos de boa capacidade de extracção (em m^3/h), baixo barulho (dB) e baixo consumo (W) criei esta tabela comparativa (mais orientada para a dimensão de 100 mm de diâmetro).



É interessante ver que existem com funcionalidades como sensor de humidade, dupla velocidade (1 mais baixa com menos ruído e outra mais potente), detecção de movimento, temporizador e há alguns que cabem integralmente dentro do tubo (permitindo p.e. colocar mais que um para melhorar a capacidade de extracção) ...

quarta-feira, 15 de março de 2017

O que fazer quando se perde um telemóvel

Hoje em dia perder um telemóvel é muito mais do que perder o valor do equipamento. Temos dados, configurações, multimédia pessoal e informações importantes que também serão perdidas.


Como proceder?
Mal nos apercebemos que perdemos o telemóvel temos de telefonar para este. Caso nos atendam, perfeito; resolvemos as coisas com a boa vontade da pessoa que o tem.
Caso a pessoa que o tiver encontrado não tiver boa vontade ou esta nem atender e/ou desligar o telemóvel (ou tirar o cartão SIM deste, que equivale ao mesmo efeito) devemos dirigir-nos à polícia e declarar como roubado (não pode ser declarado simplesmente como perdido, de forma a eles poderem actuar). Ou seja, temos de declarar à polícia que alguém cometeu o crime de apropriação ilegítima em caso de coisa achada (art. 209º-2 do código penal) de natureza semi-pública. Não esquecer de indicar todos os detalhes da situação à polícia: dizer o percurso que fizemos, até onde nos lembramos de ter o telemóvel connosco, a hora mais provável da ocorrência, se havia câmaras no local (para eles irem buscar os trechos de vídeo), etc.
Não devemos ir à operadora pedir o bloqueamento do telemóvel, de forma ao equipamento ficar o mais natural possível: para este continuar a ser usado e a polícia o poder encontrar, e para o criminoso ter menos necessidade de o alterar.
Se estivermos num local que tenha perdidos e achados devemos também tentar verificar aí se alguém o entregou.

A polícia vai pedir ao tribunal autorização para a operadora detectar que cartão ou cartões SIM está a usar ou usaram o telemóvel com aquele IMEI. Para isto temos que saber o IMEI do nosso telemóvel que se encontra presente p.e. na factura de compra.
Caso ainda tenhamos activado algum sistema de localização do telemóvel (ex.: iPhone, Samsung, Android), poderemos ter uma noção de onde ele anda e fornecer essa informação à polícia.

Infelizmente o tempo de aprovação do tribunal para dar permissão à operadora para fornecer informações à polícia é de aproximadamente 1 ano! Mas de qualquer modo, mesmo assim, vale sempre a pena a espera e não deixar o crime incólume.
(Esperemos que estas autorizações passem a ser mais automáticas no futuro porque em processos simples como estes não faz sentido tanto tempo e burocracia a entupir o sistema judicial.)

Após obter estas informações sobre que pessoa ou pessoas terão usado o nosso equipamento, será relativamente fácil para a polícia recuperar o dispositivo.

quarta-feira, 1 de março de 2017

Software Development Process - Mono or Multi Code Versioning Repository?

When we have a large software project it may make sense dividing to conquer, and create several modules that are independently developed (that may be maintained by different teams and using different programming languages).
But, regarding the versioning system, is it a better option to have each module in its own code repository (multi repositories) or have all the project's modules in 1 same repository (monolithic or mono repository)?
And if we have several independent products/projects that are unrelated (but may share common libs)?

Mono-repository
Advantages
  • Simplifies synchronization between modules
  • Simplified dependency management[4]
  • The main project will build with that checked out code for sure - 1 source of truth
  • Extensive code sharing and reuse[4]
  • Easier to refactor code project wide (like changing an interface and all its callers/users at once) Better continuous modernization. We know better who is using what. [12]
  • Easier to revert project wide changes (bug fix, refactors, features) e.g. by cherry picking at the same time in every module
  • We can tag or branch several modules at the same time (with the correct dependency)[12]
  • Atomic changes: Easier to bug fix or add new feature that require making large changes throughout all code base. "SVN, hg, and git have solve the problem of atomic cross-file changes; monorepos solve the same problem across projects."[13]
  • Better Collaboration across teams[4]
  • Flexible team boundaries and code ownership[4] that make a monorepo more capable of enforcing a more modular code (this may be counter intuitive).[14]
  • Code visibility and clear tree structure providing implicit team namespacing.[4]
  • Faster general build as we have parallelized build of all modules and submodules and less binaries copies, and optimal incremental build
  • Easier to associate with issue tracking applications
Disadvantages
  • Exaggeratedly large projects are not supported in standard VCS/SCM (e.g. git isn't scalable) as it becomes more and more unfeasible (network traffic) and time consuming to work with, as the number of commits, branches/tags and files and disk size grows. [1]
    • Many commits: Slow to do git log or blame commands
    • Many Ref advertisements: Slow to do git clone, fetch or push
    • Many tracked files: Slow git status and commit
    • Large files: Affects general repo performance and network
    • Combination of above: Hard to to switch betweens refs, 
  • If several products coexist, tags for 1 product are also made in the others (as there is only 1 tree)[1]
  • We need to have an extra work syncing the several teams that work in the same repo (for the common code between projects)[12]
  • A developer may checkout code that doesn't need to use (instead of a small subset of the repository) [15]
Possible fixes
  • Binaries:
    • use Git LFS to reduce the size of the repository, extracting the binaries (and their versions) to a secondary place (e.g. images)
    • OR tweaking the usage of delta commits for some binary types in .gitattributes[3]
      • delta off for binary files that change significantly
      • running the garbage collection (see below)
  • git-describe allows to have a separate versioning number for each module
  • git shallow clone - copy only recent revisions; or clone only one branch [3]
  • Running the garbage collection: "After a git gc refs are packed in a single file and even listing over 20,000 refs is fast (~0.06 seconds)"[1]
  • Consider removing refs you don't need anymore[1]
  • git filter-branch - clean you repo [3]
  • git sparse-checkout - keep the working directory clean by explicitly detailing which folders you want to populate [3]
  • Use Mercurial with extensions as Facebook (hgwatchman + remotefilelog extensions)[7] [8]
  • Use proprietary SCM like Google Piper[4]


Multi-repository
Advantages
  • In the rare case of different modules needing different versions of a same library (that should be avoided by all means), maintenance is easier. (But if this library depends in more common modules, we maybe don't want to also duplicate these)
  • This creation of each module as a project reinforces isolated library development (but this may be also done in a monorepository)
  • Lighter repositories to work with (fewer historic, files and size)
  • It may make sense to separate open-source code from copyright code.[14]
  • Good when we need to lock access just to some code parts
Disadvantages
  • As it is hard to predict all dependencies evolution in advance and as modules may be grouped in better ways than currently, multirepo will be harder to evolve (specially when using Agile) [9] (Harder to move code from one place to another)
  • Harder and slower to understand the implications of a modules' code changes in another module's (even if catched in a unit test)
  • Harder and slower to find a bug due to a module's code changes in the full final project
  • Slower to make the general build, as modules must wait for their dependency modules to build first (submodules aren't in the same solution and this means slower build)
    • Making a change to a project's module (even if very small) requires a release just for that module that even may fail due to many reasons such as build server network, disk space, etc.
  • Hard to coordinate horizontal changes in the all project (project wide changes):
    • Update a lib that many modules use
    • Cases of bug fix or new feature that need to be implemented along all the modules
    • Large, atomic refactorings more difficult
  • Harder to promote consistency (standardization) among the different modules:
    • Harder to promote same libraries usage (to avoid having several libraries and code that do the same thing)
    • Harder to promote same code style
    • Harder to have same versioning system usage (branches/tags names, commits descriptions)
      • Harder for a developer to move across teams (imagining each team is working in a module)
  • Less direct to get a full project build version
  • Less direct to test a project build as a whole.
  • We need a tool to help manage the project build dependencies (which version from which modules)
    • In a  more than 1 level dependency hierarchy, we have to make sure that level-2-or-up modules have the same version project wide (unless that is really pretended, but should be avoided in order not to duplicate modules - see above)
    • If a project build may have duplication of a same module with different versions, support for this must be implemented (e.g. create folder with name+version to distinguish)
    • We need to have 1 of the 2: 
      • A project wide version decision place (easier to avoid different module versions, but each module must go to this central place to know which libraries versions to use - not self contained)
      • OR have each module choosing its own dependencies and versions (harder to avoid different module dependencies, as the full dependency tree must be generated each time).
  • We will lose many time, tracking down and fixing dependency issues[13]
  • New developers spend more time learning the VC structure before they can start coding.[15]
  • We may feel more incentivized to use the dlls that are generated by each module-repo to send directly to a production environment, without updating the full project version. (This will be a pain to track what versions combination each client has - problems occur and we have to bug fix what exactly?)
Possible fixes
  • Mandatory to have a tool to help maintain, sync and make sense of the repositories dependencies
  • Use gitslave that is a sync tool between a super-project and theirs slave repositories[2]
    • This allows to use commands (such as branch, commit, push, pull, merge, tag, checkout, status and log) project wide
  • Use git-subtree
  • Use submodules [11] (but with a lot of problems)
  • Sourcetree and Smartgit [12]
  • git-repo


Summary Table

TBD


Examples
  • Spotify uses a monorepository [5] [6]
  • Facebook uses a monorepo with Mercurial with hgwatchman + remotefilelog extensions (and this resisted the test of time; they've said scaling constraints of the source control system should not dictate their code structure/organization) [7] [8]
    • (17 million lines of code and 44,000 files @ 2013)
  • Google uses a monorepo with its custom SCM named Piper (implemented on top of  Spanner) and developers access it via CitC: "Clients in the Cloud" application.[4]
    • (1 billion files (2 billion lines of code in 9 million unique source files), 35 million commits, 18-year historic, 86TB)
    • Example from an insider on how well works Google code sharing
  • Linux kernel uses a monorepo (15 million lines of code)[14]
  • Twitter, Digital Ocean, and Etsy uses monorepo[13]
  • From my experience, working with several SVN repositories with several levels of dependencies, forced the creation of a complex custom dependency management system (in Python). Core modules that existed at the bottom of the dependency hierarchy were afterwards avoided to be changed in order to simplify dependencies update and make faster builds (avoiding many intermediary modules builds). Direct dependencies creation to this core methods were also avoided in order to reduce the number of dependency links (we want less places to switch all project's modules versions). This means that code that was initially meant to be reused wasn't maintained or used anymore and same functionalities were rewritten in the modules above. A visual graph of the dependencies was also created (using DOT language and graphviz to generate it) in order to help understand each product state (Which modules were being used by the product? Which version was being used in each module? As only each module knows their dependencies+version, only reading through all the dependencies could give us this information and text was not a good way to quickly make sense of this data and e.g. detect if different versions of a same module are being used when that was not intended). An automatic dependencies updater tool was created in order to avoid human errors and do updates much faster (used when a module is upgraded and we want all the project to upgrade their dependencies for this latest module version), but had limitations and manual updates were frequently needed.

Some Reasoning
Having several repositories may make sense when we want to treat each one independently and operate as being a self-contained service/library for others to use. Few code sharing as well as few synchronization between the repositories is needed.
A monolithic repository is good when we want to have a code structuring that promotes code reuse.
In case of doubt, I choose mono.


References

terça-feira, 29 de novembro de 2016

Monitores bebé

Esta informação pode estar algo datada mas penso ainda assim ser bastante interessante já que alguns tópicos são sempre actuais.


Quando analisei as câmaras e monitores para vigiar bebés (2013), coloquei a hipótese de comprar apenas uma câmara que transmite pela rede Wireless de casa para smartphones e tablets mas ao analisar as aplicações Android e Apple não me pareceu que fossem tão fiáveis, nem tão práticas, como ter um equipamento dedicado. Isto porque há questões relacionadas com standby e som, não ter botões físicos e mostradores dedicados que a meio da noite (ex: 4h) e cheios de sono, são questões que não queremos ter de todo.

Acabamos por comprar uma Samsung, depois uma Chicco e posteriormente necessidade de comprar uma da Imaginarium. Fica a revisão de todas:

  • Samsung (SEW-3037WN):
    • Qualidades:
      • Controlo remoto da orientação da câmara
      • Ecrã desliga totalmente no modo VOX ( )
      • Botão on/off câmara e receptor é fácil/rápido de usar
      • Caso vá a electricidade abaixo, mal venha acima fica logo a funcionar
      • Permite falar remotamente com o bebé
      • Indica visualmente volume de som que o bebé está a fazer (permite estarmos com o receptor sem som ou estarmos num ambiente ruidoso como uma festa, e ter uma noção)
    • Defeitos: 
      • De vez em quando dá um apito e coloca automaticamente o volume no máximo e activa o som com o ecrã desligado, ficando nós a ouvir ruído de fundo altamente amplificado (quando a meio da noite queremos o volume no mínimo para não acordar com todos os minúsculos ruídos do bebé). Isto torna-se cada vez mais frequente com o tempo.
      • Quando a electricidade é ligada ele liga, por omissão, a luz de presença.
    • Notas: Foi comprado em 2013 via ebay do Reino Unido porque na altura não se vendia em Portugal (agora já vendem). Foi para a garantia passado 1 ano (no limite da garantia do Reino Unido) porque a câmara deixou de enviar som; o equipamento de substituição (2014) veio com as mesmas qualidades e defeitos do primeiro (e não voltou a avariar)
  • Chicco (Baby Monitor Video Digital):
    • Qualidades:
      • A bateria avariou já passados 2 anos e foi trocada de graça (mas demorou 1 mês a chegar)
      • Um carregador extra custa apenas 5€ na Chicco
      • Indica visualmente volume de som que o bebé está a fazer (permite estarmos com o receptor sem som ou estarmos num ambiente ruidoso como uma festa, e ter uma noção)
    • Defeitos:
      • Em standby, ecrã permanece com retro-iluminação ligada para dar informações de volume, VOX, qualidade da comunicação e bateria. Isto dá muita luz no nosso quarto.
      • Quando a electricidade vai abaixo é necessário ir ao quarto ligar a câmara (basta o quadro disparar por segundos)
      • Para ligar (câmara ou receptor) é necessário carregar no botão durante alguns segundos
      • Pouco alcance de transmissão
      • Não permite controlo remoto da orientação da câmara
      • LED indicador dá muita luz no quarto do bebé
      • Apita repetidamente quando não tem bateria de modo excessivamente rápido (irritante)
      • Apita exageradamente quando perde transmissão (o que ocorre frequentemente)
      • Não permite falar remotamente com o bebé
      • Carregador (transformador) estraga-se facilmente nas extremidades
    • Notas: Comprado por volta de 2013/2014
  • Imaginarium (versão de 2015):
    • Qualidades:
      • Controlo remoto da orientação da câmara
      • Indica temperatura do quarto
      • Tem músicas para o bebé acalmar
    • Defeitos:
      • Caso a câmara esteja muitos dias seguidos ligada, por vezes entra em erro e direcciona a câmara toda para cima ou toda para baixo (só desbloqueia e recupera desligando e voltando a ligar a câmara; via receptor não é possível fazer nada)
      • Quando a electricidade vai abaixo é necessário ir ao quarto ligar a câmara (basta o quadro disparar por segundos)
      • Para ligar (câmara ou receptor) é necessário carregar no botão durante alguns segundos
      • LEDs indicadores dão muita luz no quarto do bebé ("dá muito sol" segundo a utilizadora)
      • Falar remotamente com o bebé não funciona bem porque tem um atraso muito grande
      • Indicador visual de som dá muita luz, bem como os indicadores de standby pelo que têm de ser tapados (ex: papel e fita-cola) para não dar tanta luz no quarto dos pais.
    • Notas: Comprado em finais de 2015

Defeitos comuns a todos:
  • Câmara não dispõe de bateria para aguentar transmissão enquanto a electricidade está em baixo
  • VOX é activado por som, mas poderia ser também por movimento excessivo do bebé
Qualidades comuns a todos:
  • Troca entre modo de visão diurna e nocturna (via infra-vermelhos) é automática
Notas:
  • A visão nocturna é a mais importante, uma vez que a câmara é maioritariamente usada enquanto o bebé dorme (ao contrário do que sugerem as ilustrações). 
  • No nosso caso não encontrámos utilidade para a luz de presença, que pode ser ligada nas câmaras. 
  • O modo de colocação da câmara melhor (grande amplitude de imagem de modo a não termos de estar constantemente a ajustar remotamente a direcção da câmara) é numa tomada de parede superior (normalmente existentes para colocar TVs) onde a câmara fica agregada ao transformador.

Será que surgirá um dispositivo perfeito no futuro?

quinta-feira, 17 de novembro de 2016

O tempo perdido, o tiro pela culatra, a vingança, a mentira e o tendenciosismo [opinião]


[Nota prévia: Artigo de opinião não baseado directamente em qualquer estudo]


Quando tomamos algo como verdade e vemos que o mundo não a está a ver e está até a distanciar-se desta; poderemos puxar a coisa para o nosso lado tendenciosamente; ou seja, demasiado para um lado pensando que assim irá ser melhor (mais rápido) para a sociedade fixar-se na verdade central.
No gráfico seguinte temos a opinião pública num lado e a tentativa de disseminar uma ideia no campo oposto:
Acontece que ao puxar demasiado, para além da verdade (sermos tendenciosos) para qualquer que seja o lado, estamos na verdade a perder força no nosso argumento, a perder credibilidade mais tarde ou mais cedo, pois vai-se descobrir que a verdade não é tão exagerada. Estamos ainda a dar força à mentira oposta, no sentido que muita gente poderá pensar que se nós estamos errados então o outro lado será o correcto.
No curto prazo poderemos mudar mais rapidamente a média da opinião pública para o nosso lado ( ) mas a longo prazo perdemos tempo para obter o resultado final estabilizado e perdemos energia colectiva que poderia ser usada noutras coisas (estamos a criar divisão de ideias na sociedade quando deveríamos criar convergência):
 A minha visão é que se apontarmos logo de início para o caminho final, chegámos lá todos mais rapidamente:
Já temos a verdade e a mentira, o tendenciosismo e o seu tiro pela culatra, e o tempo perdido. Onde entra a vingança?
A vingança é exactamente o fazer aos outros aquilo que não gostámos que nos façam a nós. É dizer uma mentira para tentar corrigir a injustiça de outra mentira. É cometer um crime para tentar compensar outro crime. Para mim, é criar confusão escusada e não apontar logo para o caminho certo.

Toda esta teoria se aplica em inúmeros exemplos da nossa vida: política, negócios, saúde, educação, relações pessoais, justiça e até mesmo na ciência.

Qual a vossa opinião?

quinta-feira, 8 de setembro de 2016

Peças e Reparações

Uma das coisas que me faz mais "espécie" é o deitar fora coisas.
  • Quando algo parte ou avaria, o deitar fora e comprar novo também não me parece que seja muito benéfico para a economia, pois parece-me melhor forma de consumo usar um serviço que comprar um produto. O serviço está mais directamente ligada ao salário das pessoas e usa menos recursos materiais. Enquanto um problema do consumismo de produtos é a pegada ambiental associada, o uso de serviços é mais amigo do ambiente.
  • Neste caso o serviço é a reparação e venda de peças (que até podem ser usadas).



Aqui há uns anos, por exemplo, estraguei (derreti) um filtro de aspirador mas pesquisei e comprei um baratissimo na Mavegon.
Ainda bem que arranjei porque seria um disparate deitar um aspirador funcional fora só porque faltava uma peça.

ORIGINAIS

Locais de peças e reparações que conheço:
  • Braga:
  • Porto:
    • Mavegon - (AEG, Electrolux, Zanussi, Candy, Hoover, Iberna, Rosieres, Nilfisk, Framtid, Renlig, Lidden, Lagan, Frostig, Ikea)
    • Narsil - Narciso & Silvia, Lda (Braun, ...)
    • Citytec - (Samsung, Worldpool, Indesit, Ignis, Hotpoint, ...)
    • A.J.Pinto - (Teka, Best, Alfa, Remington, Russel Hobbs, Hergom)
[pfv sugerir outras]

3D

Quando não arranjamos as peças nas marcas, podemos sempre imprimir numa impressoa 3D.
Com um bocado de sorte podemos encontrar o desenho já feito e pronto [1] [2] a imprimir.
O material a usar para fazer a peça varia conforme a necessidade (podemos p.e. querer maleável ou rigido) e existem impressoras dedicadas a cada tipo (ou grupos de tipos). Existem já dezenas de materiais diferentes como podemos ver na all3dp.
Se não quisermos investir em comprar uma impressora, podemos usar o serviço de imprimir [3] [4].

quinta-feira, 25 de agosto de 2016

EDP comercial

Já tinha publicado um artigo em que referia a falta de seriedade da EDP comercial, o que me levou a um comparativo entre fornecedores de energia.
Na altura, realizei um contrato com descontos na eletricidade e no gás que não foram aplicados na prática! Também não me enviaram um contrato escrito! Também a leitura do contador de electricidade (realizada por empresas subcontratadas) foi errada (pelo que imagino que devam ter usado uma estimativa por alto e indicado tal como leitura real!), situação que se revelou especialmente problemática na troca entre comercializadores.

Agora surge-me um contacto telefónico da EDP comercial do 937310034 a propôr o serviço "factura segura" (que depois me vim a aperceber que era na prática um seguro).
Via telefónica disseram que ficariamos com 400€ para pagar facturas caso entremos de baixa médica ou entremos em situação de desemprego involuntário apenas pelo preço de 0,05€/dia. Haveria 60 dias de periodo de carência mais 30 dias de espera.
Ou seja, se ficasse de baixa ou desempregado, passados 90 dias de contrato teria 400€ para as contas da energia.
Questionei se uma pessoa já desempregada poderia aderir e ter os 400€ passados 3 meses e disseram-me que sim, que bastaria enviar depois o certificado do centro de emprego da situação de desemprego!

Bom demais para ser verdade? Claro!
Encontrei logo um pdf com o contracto no site da EDP e claramente diz que quem contrata tem de desenvolver "uma atividade profissional remunerada" há já pelo menos 12 meses.

Pode-se ainda ler no ponto 7. EXCLUSÕES GERAIS, onde ficam excluídas as situações onde o sinistro tenha ocorrido antes ou durante o periodo de carência do contrato ou se já saiba que vá ocorrer.
As 3. EXCLUSÕES ESPECÍFICAS excluiem ainda gravidez, contractos com termo, rescisão no período experimental (mesmo a contractos sem termo), despedimento com justa causa, etc
Facilmente encontramos queixas de muita gente para com este serviço e também relativas ao serviço "funciona".
As mentiras telefónicas deverão ser muitas.

Mais uma vez a EDP comercial comprovou não ser uma entidade de bem, pois se fosse, por exemplo, teria de exigir o contrato de trabalho do cliente para iniciar este tipos de contractos; bem como enviar o contracto (com todas as letrinhas miudinhas) para o cliente ler antes de assinar ou indicar que sim por telefone; algo que claramente não faz.



terça-feira, 19 de abril de 2016

Débitos Directos - Cuidado!

Eu era fã dos débitos diretos. Deixei de o ser.

Os débitos directos (DD) facilitam a vida aos clientes porque automatizam os pagamentos, evitando o pagamento manual todos os meses de todas as coisas (electricidade, gás, água, seguros, telecomunicações, etc) e é bom para as entidades que garantem um pagamento mais certo por parte dos clientes.

Acontece que desde 1 de Agosto de 2014 as regras do DD mudaram, em cumprimento das regras europeias SEPA (“Single Euro Payments Area” ou “Área Única de Pagamentos em Euros”) [2]:
Estes passam a ser autorizados sem a participação dos bancos!
No inicio de 2016, apercebi-me do quão inseguro está o nosso dinheiro agora devido aos DD.

Mudei de seguro automóvel da Zurich (via mediador) para a Direct- (telefone). De forma a proceder à mudança, na Direct-, disseram-me que nem precisava de informar a Zurich e só precisaria de desactivar o DD no banco. Eu, no entanto, informei o mediador de seguro que pretendia terminar o seguro e inactivei o DD no site do banco.
2 meses depois terminaria o 1º seguro e começaria o 2º; Só que aconteceu que começaram os 2!
A Zurich, mesmo que o mediador não lhe tenha reencaminhado o meu pedido de cancelamento, tem a informação (no sistema informático das seguradoras) que o veículo teria passado a ser asegurado por um novo seguro. Mesmo assim, a Zurich solicitou a re-activação do DD ao banco (com base no documento assinado antes de eu ter inactivado o DD) e procedeu ao levantamento do dinheiro. E os bancos, agora, não tem de confirmar nada!
Apesar de eu ter visto o movimento no extracto bancário, na data, só passado 3 meses é que verifiquei que era relativo a um seguro que eu pensava já não ter. No ActivoBank disseram-me que os DD eram inactivados e não cancelados e que até 60 dias poderia ter o dinheiro devolvido mas já tinha passado o prazo não havia nada a fazer!
Interpelada a CGD por estas questões referiram-me prazos 30 dias (mensagem do gestor) e 47 dias (ao balcão) para a devolução. Já a DECO refere 13 meses para reclamar junto do banco e solicitar o reembolso de valores indevidamente cobrados; e indica que deve ser feita queixa-crime. [1]

Após investigar sobre o assunto, descobrir já ter havido a situação de uma associação desportiva descobrir que o seu NIB estava a ser usado por uma pessoa para pagar um serviço da Meo. [1]
A relação "NIB" - "nome do titular" não foi verificada pela entidade credora ou pelo banco?

Dirigindo-me a um balcão da CGD para entender a fundo o ponto de situação dos DD, concluí que:
  • Na CGD, não há actualmente qualquer forma de cancelar permanentemente um DD unilateralmente; Isto apenas é possível com o aval da entidade credora (que pode não ser de bem)! O cliente pode apenas proceder à inactivação do DD, que é facilmente reactivado pela entidade a qualquer momento.
    • E isto apesar do Banco de Portugal indicar que o consumidor tem o direito a criar uma lista de entidades autorizadas e uma lista negra! Este direito, pura e simplesmente, está a ser negado na prática pois apenas nos é permitido "inibir" um DD (mesmo ao balcão). [2]
  • A única forma de cancelar um DD é impedir a totalidade dos DD, ou seja, quaisquer cobranças por DD são bloqueadas.
Imaginemos agora que há uma entidade que sabe o meu NIB e forja um documento supostamente assinado por mim. Não há uma maneira simples e directa de cancelar isto, só podemos inibir temporariamente?

Deixem, por favor, comentários de forma a podermos melhorar este artigo, tornando-o mais completo e fácil de entender.


Referências:
[1] https://www.publico.pt/economia/noticia/debito-directo-1690354
[2] https://www.bportugal.pt/pt-PT/OBancoeoEurosistema/ComunicadoseNotasdeInformacao/Paginas/combp20140801.aspx

sexta-feira, 8 de abril de 2016

Paraísos Fiscais

Os problemas que os paraísos fiscais criam são conhecidos há muitos anos, e logo com um grande nível de certezas das suas implicações reais. 
Desde o grande crash mundial de 2007 (que também levantou esta crise que Portugal atravessa) isto começou a ser mais falado. Só que agora, com a mega investigação jornalistica "papéis do Panamá", temos nomes e números:
Deixo uma análise que não parece estar a ser feita e divulgada.
Reparem nos gráficos seguintes: 






Há aqui uma clara maior actividade no período pré-crise global.
Isto poderá indicar que (1) as pessoas poderosas (que são típicamente quem usa os paraísos fiscais) já sabiam que iria ocorrer o crash e desviaram o seu dinheiro para o proteger;
E/OU poderá (2) ter havido, na altura, um maior interesse em fugir a impostos e uso de offshores para p.e. comércio de armas para os conflitos mais recentes e outras actividades ilegais, e isto ter gerado o próprio crash. Pelo menos que potenciou o crash não há grandes dúvidas disso.

Deixo também a nota que o Reino Unido tem um papel preponderante neste problema e, como tal, também deverá ter um papel importante para o resolver (vejam os gráficos referentes às nacionalidades no mesmo link).

domingo, 21 de junho de 2015

Evolução do PIB/capita

Só agora é que reparei, de forma clara, que desde o 25 de Abril de 1974 (embora com um arranque lento) o PIB/pessoa aumentou até ao crash de 2008.

Fonte: http://www.pordata.pt/Portugal/PIB+e+rendimentos+per+capita-534

No entanto a preços constantes (base 2011), eliminando a inflação, temos um crescimento desde antes do 25 de Abril mas claramente ainda a mostrar que este crash de 2008 foi enorme. De facto teve mais influência no nosso país que a revolução de 1974!
Para mim, é a prova que estamos totalmente globalizados e temos que conhecer e tomar ações a nível mundial, se queremos controlar os destinos da nossa casa!



"Quando se procura comparar ou analisar o comportamento do PIB de um país ao longo do tempo, é preciso diferenciar o PIB nominal do PIB real. O primeiro diz respeito ao valor do PIB calculado a preços correntes, ou seja, no ano em que o produto foi produzido e comercializado. Já o segundo é calculado a preços constantes, em que é escolhido um ano-base para o cálculo do PIB, eliminando assim o efeito da inflação. " (https://pt.wikipedia.org/wiki/Produto_interno_bruto)