Anaerobic organisms have molecular systems to detoxify reactive oxygen species when transiently exposed to oxygen. One of these systems is superoxide reductase, which reduces O2 (.-) to H2 O2 without production of molecular oxygen. In order to complete the reduction of superoxide anion, superoxide reductase requires an electron, delivered by its redox partners, which in Desulfovibrio gigas are rubredoxin and/or desulforedoxin. In this work, we characterized the interaction of Desulfovibrio gigas superoxide reductase with both electron donors by using steady-state kinetics, 2D NMR titrations, and backbone relaxation measurements. The rubredoxin surface involved in the electron transfer complex with superoxide reductase comprises the solvent-exposed hydrophobic residues in the vicinity of its metal center (Cys9, Gly10, Cys42, Gly43, and Ala44), and a Kd of 3 muM at 59 mM ionic strength was estimated by NMR. The ionic strength dependence of superoxide-mediated rubredoxin oxidation by superoxide reductase has a maximum kapp of (37 +/- 12) min(-1) at 157 mM. Relative to the electron donor desulforedoxin, its complex with superoxide reductase was not detected by chemical shift perturbation, though this protein is able to transfer electrons to superoxide reductase with a maximum kapp of (31 +/- 7) min(-1) at an ionic strength of 57 mM. Competition experiments using steady-state kinetics and NMR spectroscopy (backbone relaxation measurements and use of a paramagnetic relaxation enhancement probe) with Fe-desulforedoxin in the presence of (15) N-Zn-rubredoxin showed that these two electron donors compete for the same site on the enzyme surface, as shown in the model structure of the complex generated by using restrained molecular docking calculations. These combined strategies indicate that the two small electron donors bind in different manners, with the desulforedoxin complex being a short lived electron transfer complex or more dynamic, with many equivalent kinetically competent orientations.

A programação concorrente obriga o programador a sincronizar os acessos concorrentes a regiões de memória partilhada, contudo esta abordagem não é suficiente para evitar todas as anomalias que podem ocorrer num cenário concorrente. Executar uma sequência de operações atómicas pode causar violações de atomicidade se existir uma correlação entre essas operações, devendo o programador garantir que toda a sequência de operações é executada atomicamente. Este problema é especialmente comum quando se usam operações de pacotes ou módulos de terceiros, pois o programador pode identificar incorretamente o âmbito das regiões de código que precisam de ser atómicas para garantir o correto comportamento do programa. Para evitar este problema o programador do módulo pode criar um contrato que especifica quais as sequências de operações do módulo que devem ser sempre executadas de forma atómica. Este trabalho apresenta uma análise estática para verificação destes contratos.

Os serviços Web são frequentemente suportados por sistemas com uma arquitetura em camadas, sendo utilizadas bases de dados relacionais para armazenamento dos dados. A replicação dos diversos componentes tem sido uma das formas utilizadas para obter melhorarias de escalabilidade destes serviços. Adicionalmente, a utilização de bases de dados em memória permite alcançar um desempenho mais elevado. No entanto é conhecida a fraca escalabilidade das bases de dados com o número de núcleos em máquinas multi-núcleo. Neste artigo propomos uma nova abordagem para lidar com este problema, intitulada MacroDDB. Utilizando uma solução de replicação hierárquica, a nossa proposta, replica a base da dados em vários nós, sendo que cada nó, por sua vez, executa um conjunto de réplicas da base de dados. Esta abordagem permite assim lidar com a falta de escalabilidade das bases de dados relacionais em máquinas multi-núcleo, o que por sua vez melhora a escalabilidade geral dos serviços.

Lipid-modified azurin (Laz) from Neisseria gonorrhoeae is a type 1 copper protein proposed to be the electron donor to several enzymes involved in the resistance mechanism to reactive oxygen and nitrogen species. Here we report the backbone and side-chain resonance assignment of Laz in the reduced form, which has been complete at 97 %. The predicted secondary structure indicates that this protein belongs to the azurin subfamily of type 1 copper proteins.

In order to gain insights into the interplay between Cu(I) and Cu(II) in sulfur-rich protein environments, the first preparation and characterization of copper-substituted forms of the wild-type rubredoxin (Rd) from Desulfovibrio vulgaris Hildenborough are reported, as well as those of its variant C42A-Rd. The initial products appear to be tetrahedral Cu(I)(S-Cys)n species for the wild type (n=4) and the variant C42A (n=3, with an additional unidentified ligand). These species are unstable to aerial oxidation to products, whose properties are consistent with square planar Cu(II)(S-Cys)n species. These Cu(II) intermediates are susceptible to auto-reduction by ligand S-Cys to produce stable Cu(I) final products. The original Cu(I) center in the wild-type system can be regenerated by reduction, suggesting that the active site can accommodate Cu(I)(S-Cys)2 and Cys-S-S-Cys fragments in the final product. The absence of one S-Cys ligand prevents similar regeneration in the C42A-Rd system. These results emphasize the redox instability of Cu(II)-(S-Cys)n centers.

The development of web applications that manipulate geo-referenced information is often supported by Application Programming Interfaces (APIs), allowing a fast development cycle for high quality applications. APIs can be used by programmers with different expertise levels and choosing an adequate API may
have a dramatic impact on the productivity achieved by those programmers. Our goal is to compare maps APIs with respect to their usability. We compare three different APIs: the Google Maps JavaScript API, the ArcGIS API for JavaScript, and the OpenLayers JavaScript Mapping Library. Our comparison is supported by
a set of software metrics and is performed in two orthogonal ways: the comparison of three implementations of the same system prototype, each using one of the APIs under scrutiny; the comparison of the APIs specifications. The main results of the study are related to the size of the APIs, with the Google API being significantly smaller than the others.