Investigadores do Instituto Wake Forest para a Medicina Regenerativa desenvolveram uma impressora 3D que é capaz de gerar tecido de substituição suficientemente forte para aguentar um transplante.

Trata-se do Integrated Tissue and Organ Printing System (ITOP), resulta de um trabalho de 10 anos e, para comprovar a sua eficácia, os cientistas imprimiram osso de maxilar, músculo, cartilagem e até uma orelha.

A ITOP funciona de forma similar às impressoras 3D convencionais, sendo que utiliza biomateriais como matéria-prima, revela o Gizmodo. Outro factor diferenciador é a capacidade de criar estruturas estáveis para transplante cirúrgico, onde se incluem micro-canais que funcionam como vasos sanguíneos e permitem transportar nutrientes e oxigénio às células.

Os detalhes desta inovação foram divulgados na Nature Biotechnology e, depois de refinada a técnica e comprovada a segurança em humanos, espera-se que estas estruturas possam vir a ser aplicadas em pacientes. Uma vez que as peças são desenhadas por computador, o objectivo é adaptá-las às necessidades únicas de cada pessoa.



vide 
Plataforma e-NABLE: próteses por voluntários
Plataforma Portugal 3D




fonte: ExameInformatica

A ThingMaker 3D é a solução da Mattel para criar brinquedos únicos e personalizados. Esta solução inclui o software de criação e a impressora propriamente dita.

Miúdos e graúdos podem desenvolver as suas criações no telemóvel ou tablet, na app própria, e comunicar esses desenhos para a impressora 3D, noticia o Gizmodo. A Mattel estabeleceu uma parceria com a Autodesk, a empresa que faz o AutoCad, para se assegurar que o software seria simples, estável e fluído. A app está disponível para iOS e Android e já traz vários modelos de aneis, pulseiras, escorpiões, esqueletos e muito mais.

Ainda não se sabe quantas cores do filamento de plástico vão estar disponíveis no momento do lançamento, mas sabe-se que a Mattel optou por PLA (um polímero de origem orgânica), solução habitual nas impressoras 3D. Já há demonstrações com brinquedos em mais de 20 cores.

A ThingMaker 3D estará disponível a partir do Outono de 2016 e as reservas podem ser feitas no site da Amazon. Espera-se um preço próximo dos 300€, muito abaixo do preço habitual para impressoras 3D prontas a utilizar.





fonte: ExameInformatica

Este serviço permite criar funções em JavaScript que respondem automaticamente a eventos cloud sem ser necessária a intervenção do utilizador, configuração e execução de um runtime ou escalá-las por várias várias máquinas.


Podem haver vários eventos num ambiente cloud propagados de forma assíncrona através da infra-estrutura Cloud Pub/Sub. O utilizador pode configurar um trigger que fica à escuta destes eventos e lhes responde executando código JavaScript num ambiente Node.js.
Neste momento, os triggers podem ser activados através dos seguintes canais:

1. Cloud Pub/Sub - evento Pub/Sub assíncrono
2. Cloud Storage - notificações de alterações de um objecto
3. HTTP Invocation - invocação síncrona por HTTP
4. Debug/Direct Invocation - utilização da CLI Command Line Interface para desenvolver/depurar as Cloud Functions

O que a Google diz sobre as Cloud Functions:

The function can access any other cloud resources that have appropriate Node (JavaScript) client libraries or RESTful APIs. If you use the gcloud-node client libraries you're automatically authenticated with the default project credentials, so you don't have to worry about generating or storing auth keys etc.
The function has full access to the internet so you can call out to any 3rd party API, however you'll have to maintain your own auth keys etc for these external services.

A arquitectura de software é o esqueleto de qualquer sistema. É a arquitectura que define o comportamento do sistema no que toca aos requisitos, tanto funcionais como não-funcionais. Ao passo que o modelo em cascata é rígido, o modelo ágil é mais flexível às alterações dos requisitos e essas alterações podem implicar a própria arquitectura. Uma arquitectura Agile permite a expansão sustentável do sistema de forma gradual, simples e actualizável à medida que o projecto se torna mais complexo.

Enquanto que a arquitectura é uma actividade que ocorre uma vez no modelo em cascata com datas de início e fim bem definidas, numa abordagem ágil a arquitectura é um processo contínuo sem uma data de fim estipulada. Portanto, em Agile a arquitectura pode ser regularmente sujeita a alterações.
As alterações a um projecto são aplicadas através do desenvolvimento iterativo e incremental. No Scrum estas iterações são os chamados sprints (duram entre duas a quatro semanas). Qualquer alteração é celeremente discutida e, dada a focalização da framework na colaboração entre a equipa, toda a questão é imediatamente resolvida entre os seus membros. Uma vez que a arquitectura é o esqueleto, é muito sensível à mudança. A alteração à plataforma terá impacto em várias iterações e, no limite, levará à reengenharia do projecto.

Principais responsabilidades do arquitecto tradicional

Focar-se no todo

Deve considerar como é que o sistema vai ficar dentro de alguns meses (ou anos) e também deve considerar os sistemas envolvidos e a comunicação entre eles.

Ser orienteado à compliance

Deve ter em consideração as questões de compliance como sejam leis, licenças ou standards.

Produzir blueprints

Documentos e diagramas que descrevem a arquitectura sob várias perspectivas. Estes são os entregáveis usados para a implementação do sistema.

Não precisa de muita experiência prática

O que o arquitecto tem de fazer é produzir os entregáveis para a equipa de desenvolvimento. Ainda que tenha experiência como developer, o seu papel está mais focado na orientação da equipa na construção do sistema desenhado.

Principais responsabilidades do arquitecto Agile

Ponderar o equilíbrio entre o agora e a visão global

Tem de pensar no que está a acontecer durante o desenvolvimento e enquadrá-lo com a visão global de todo o sistema.

Experiência prática

É também developer e trabalha na implementação do sistema, o que lhe permite avaliar os resultados das decisões de arquitectura de forma directa.

Produzir protótipos para tomar decisões informadas

Um protótipo ou uma prova de conceito podem revelar se uma decisão é ou não fazível e como afecta o sistema. É um trabalho colaborativo de comunicação com a equipa e não uma tarefa isolada.

Focar-se na sustentabilidade

As decisões são feitas para conseguir uma arquitectura sustentável, uma que suporta o sistema a longo prazo. Competências pessoais essenciais são o sentido de responsabilidade e a empatia. Enquanto membro da equipa, experimenta em primeira mão os resultados das suas decisões, o que aumenta a sua responsabilidade face à abordagem em cascata, na qual as decisões transitam para a equipa que as implementa.

Duração de uma arquitectura de software Agile

O importante da arquitectura é saber quando é que tem que começar, porque no modelo Agile não há um momento pré-determinado para se começar uma fase. Tipicamente usa-se o sprint #0, um sprint especial para configuração do ambiente de desenvolvimento e tomada de decisões fundamentais como linguagens de programação, plataforma, base de dados, etc. Para evitar deslizes no período de tempo destinado a estas actividades é previamente acordada uma data de fim (iteração de duração idêntica às iterações regulares) para então se dar início aos sprints normais.
Dificilmente a arquitectura estará pronta quando os sprints seguintes começarem, mas a definição de uma arquitectura ágil é um processo contínuo. Não é possível por de pé um sistema sem garantir que a arquitectura o suporta.

Agile teams don't necessarily create agile software architectures.
But a good architecture enables agility.

~Simon Brown

Princípios Determinantes

Para não complicar demasiado as coisas na elaboração da arquitectura (que podem custar caro ao desenvolvimento), há dois princípios a seguir na tomada de decisões:

• Keep It Simple, Stupid (KISS)
• You Aren’t Gonna Need It (YAGNI)

Estes dois princípios fazem pensar se determinada feature ou decisão é realmente necessária naquele momento. Se pode ser adiada, a arquitectura mantém-se simples e fácil de gerir mais tempo, mas sem cair no erro de deixar tudo para a última da hora sob pena de tudo se tornar mais complicado, porque

we should take decisions not in the last possible moment,
but rather in the most responsible one.

Ao preparar uma decisão relativa à arquitectura, é aconselhável fazer pequenas preparações que não levem muito tempo se o grau de certeza é elevado e, claro, discutir com os colegas de equipa, não fosse a comunicação directa um dos pilares da framework.

Documentação

Numa abordagem ágil do processo de desenvolvimento de software, assim como são usadas iterações para fazer o código, também podem ser usadas iterações para gerir e manter a documentação. Começa-se pelos aspectos mais importantes do sistema e vai-se adicionando mais informação de forma contínua ao longo das iterações. Não existem ferramentas específicas para produzir documentação no mundo Agile. Podem ser desenhos num quadro branco, post-it, documentos de texto ou wikis por exemplo. Para manter os diagramas é preferível uma ferramenta como o Microsoft Visio ou o draw.io, mas existem outras ferramentas.



Relacionado: Metodologias ágeis e documentação






fonte: infoQ.com