A footnote from "Exclusion and Embrace: A Theological Exploration of Identity, Otherness, and Reconciliation", Miroslav Volf.
The metaphor of the door is helpful insofar as it implies a necessary demarcation, but it is also misleading insofar it suggests a sharp and static boundary. In analyzing the category "Christian", missiologist Paul Hiebert suggests that we make use of the mathematical categories of "bounded", "fuzzy" and "centered sets". Bounded sets function on the principle "either/or": an apple is either an apple or it is not; it cannot be partly apple and partly a pear. Fuzzy sets, on the other hand, have no sharp boundaries; things are fluid with no stable point of reference and with various degrees of inclusion - as when a mountain merges into the plains. A centered set is defined by a center and the relationship of things to that center, by a movement toward it or away from it. The category of "Christian", Hiebert suggests, should be understood as a centered set. A demarcation line exists, but the focus is not on "maintaining the boundary" but "on reaffirming the center"
Bibliography:
Hiebert, Paul G. "The Category 'Christian' in the Mission Task." International Review of Mission 72 (July 1983): 421-27.
Thursday, December 27, 2007
Tuesday, December 25, 2007
Saturday, December 22, 2007
Saturday, December 15, 2007
Púlpito ou Picadeiro?
De
http://thiagomendanha.blogspot.com/
E ele designou alguns para apóstolos, outros para profetas, outros para evangelistas, e outros para pastores e mestres, com o fim de preparar os santos para a obra do ministério, para que o corpo de Cristo seja edificado... Efésios 4:11,12 – NVI (Nova Versão Internacional)
E ele contratou alguns para superastros-ídolos, outros para cantores-popstars, outros para marketeiros-paparazzi, e outros para showman e ilusionistas, com o fim de entreter os pagantes para o show business, para que o Mercado de Cristo seja fomentado... Efésios 4:11,12 – NVA (Nova Versão Apostólica)
Thursday, December 13, 2007
Bezerra da Silva - Quando O Morcego Doar Sangue
Para tirar meu Brasil dessa baderna
Para tirar meu Brasil dessa baderna
Só quando o morcego doar sangue
E o saci cruzar as pernas
Só quando o morcego doar sangue
E o saci cruzar as pernas
Toda nossa esperança é somente lembrança do passado
A alta cúpula vive contagiada pelo micróbio da corrupção
O povo nunca tem razão, estando bom ou ruim o clima
Somente quem está por cima é a tal dívida externa
E o malandro que faz aquele empréstimo
E leva os vinte por cento dela para tirar!
Já não há alegria de noite e de dia a tristeza não pára
A vida custando os olhos da cara
E não temos dinheiro para comprar
Quem governa o país é muito feliz, não se preocupa
Tem tudo de graça, não esquenta a cuca
E o custo de vida só sabe aumentar
Antigamente governavam decente, sem sacrilégio
Hoje são indecentes, cheios de privilégio
É só caô caô pra cima do povo
Promessa de um Brasil novo
E uma política moderna
Mas só quando o morcego doar sangue
Para tirar meu Brasil dessa baderna
Só quando o morcego doar sangue
E o saci cruzar as pernas
Só quando o morcego doar sangue
E o saci cruzar as pernas
Toda nossa esperança é somente lembrança do passado
A alta cúpula vive contagiada pelo micróbio da corrupção
O povo nunca tem razão, estando bom ou ruim o clima
Somente quem está por cima é a tal dívida externa
E o malandro que faz aquele empréstimo
E leva os vinte por cento dela para tirar!
Já não há alegria de noite e de dia a tristeza não pára
A vida custando os olhos da cara
E não temos dinheiro para comprar
Quem governa o país é muito feliz, não se preocupa
Tem tudo de graça, não esquenta a cuca
E o custo de vida só sabe aumentar
Antigamente governavam decente, sem sacrilégio
Hoje são indecentes, cheios de privilégio
É só caô caô pra cima do povo
Promessa de um Brasil novo
E uma política moderna
Mas só quando o morcego doar sangue
Tuesday, December 11, 2007
Lounge Night - Ottawa Baptist Association - Youth
Ontem teve aqui o Lounge Night, promovido pelos Jovens da Associação de Igrejas Batistas de Ottawa. Foi muito bom. A líder de jovens da igreja organizou. Alugamos um lounge (tipo um bar). Um DJ da rádio cristã veio pôr músicas e ser o MC. Tivemos um mini-concurso de bandas locais. A banda vencedora ganhou uma música a ser produzida em estúdio. E outros músicos se apresentaram.
O bar fica no setor de badalação da cidade, do lado do centro (no Market).
Gostei muito do ambiente. Era pequeno, tinha dois andares. Tinha luz fraca, outras luzes coloridas e um globo espelhado no teto. A banda ganhadora era de uma escola (a maioria dos integrantes eram não-crentes. Conversei com alguns pais dos integrantes.). Da nossa igreja (nossa igreja é bem pequena, tem uns 30 membros) foram vários jovens. Dois participaram do concurso. O Nilton matou a pau com o seu rap. Ele tem gravado em Montreal. Ele me disse que a escola dele (pública) tem um estúdio. Ele pode usar o quanto quiser de graça (coisas de Canadá...). Depois de gravar na escola ele leva as gravações pra Montreal pra ficar mais
profissional. O pessoal da rádio gostou tanto que vai pôr uns raps dele no ar.
O pessoal dançou muito ao som de hip-hop e dance. Dá pra ver que não somos Batistas americanos... Quem sabe da próxima vez não abrimos o bar com umas caninhas?
Foi um lugar neutro onde crentes e não-crentes podem se encontrar, se
divertir e interagir. Foram muitos jovens que eu conheço (amigo do amigo) que não poriam o pé numa igreja. Fica a idéia.
Sunday, December 09, 2007
On RFID software
There are customers and integrators that underestimate or do not appreciate the complexities of the problems involved in delivering an RFID solution. Software for RFID is something that is currently not well documented. The knowledge is not readily accessible to developers. At this post, let us consider some aspects of software for RFID.
1 - The customer often needs enterprise software for RFID. That means a solution that focuses on the business problems (and practical problems!). More often than not RFID will be just one piece of the solution. One important piece, and one piece that requires integration. But one piece among others likely. For instance, integration between the new system and ERPs or WMSs may be required. A good integrator will approach the problem aiming at a solution.
2- This is a corollary of the point above: RFID is not just about hardware. Many people spend lots of time thinking about the physics of RFID and forget (deliberately at times) about software. Good read rates is only part of the problem. (A non-problem really for software!) Middleware is a commodity now, so think of RFID hardware as any other hardware (printers, memory, hard disks, keyboard), and begin to work on how your software will address the business problems. Forget about read rates. Leave that with the hardware providers.
3- Think about the network. More specifically, the 'cloud' and the 'edge'. More generally, RFID requires software to be distributed because tagged objects are moving! Since objects go from A to B, your software needs to be in A and B. Now thinking about common roles and scenarios where RFID is deployed into, there's the 'cloud' and there's the 'edge' more often than not. RFID software in the 'cloud' is generally for managers and IT, whereas at the 'edge' is for 'warehouse workers'. This has many implications. The first direct implication is that the software gets to be partitioned: part lives at the cloud and part at the edge. While there's room for debate over what feature should live where, some restrictions apply. There's a network penalty for the edges to access the cloud. Ideally actions that require fast response or local data (data that applies to this instance of the edge) should be accessible from the edge. For instance, gadgets at the warehouse should be controlled by software at the edge and not the cloud. Reports (which require often consolidated data from all edges) are recommended to live in the cloud. Most middleware provide control for readers in a central location, so that's not a problem. Depending on the size of the deployment, you will want to think about the replication of two elements: data and rules. Depending on the location of the ERP and WMS systems you'll have data integration in the cloud. This data, however, is likely to be used at the edge. In the second case, depending on the size of deployment again, you'll want to update business rules (or new versions of software) only at the cloud and have them to migrate to the appropriate instance of the edge.
4- Time is important in RFID implementations. To begin with there are three agents that produce 'events' (there's a word that is abused): readers, software and humans. Tag reads happen and software has no control over when they happen (that is, they happen asynchronously. Well, there are synchronous tag reads. For example, tag reads triggered by handhelds are synchronous). Processes generally have two variants: those with beginning and end, and those which are 'continuous'. You may have a human beginning and ending a process, and you may have to coordinate or fit in tag reads within the (logical) process. Most software implementations will just ignore this and code everything inside the business components. And most middleware won't model the problem. (By the way, this has nothing to do with EPC-IS... initially). The best thing you can do is to think about timing issues and think about how to model processes generically. Besides the problem of coordinating time between tag reads and processes, there's always the UI. Yes, you'll have to take into account when tag reads occur and when and how to show them in the UI. With all this, try to design the software properly... (boa sorte, meu fio.)
5- Think about location and processes. Have your terms well-defined. When thinking about processes, the two variants above may convey different meaning. For instance, a tag read in the ' continuous' case may mean that the tag underwent the process (and is 'out' of the process). A tag read in a process with beginning and end may be held by the process until it's explicitly out of the process when it ends. This is specially true when there is a group of tag reads that 'enter' a process and depend on humans to exit the process. That is, it is as if tag reads are temporarily held at the process. From a business point of view the tag reads only occurred after the tags exited the process. Define a precise vocabulary with the business peers, setting what 'location' and 'process' mean.
6- Association is important. More often than not, RFID tags are attached to something. The business is usually interested in this something and not the tag itself! So think about tag associations. (One sample question to the customer: 'Are objects always associated to the same tag forever?')
7 - Think about when to use handhelds and when to use fixed readers. The primary business decision relates to labour and hardware costs. However, think about the differences for software. Mobile software is a subject that is vastly documented and explored, so there's no need for me to write too much about it. Software on handhelds must take into account network constraints (on-off connectivity, operating disconnected if needed, network latency, control of software version, manageability of software updates, etc), synchronization challenges (collecting or changing data offline), limited displays and resolutions (which requires a whole rethinking of the UI and usability), etc. Also, bear in mind that most middleware to-date are for non-mobile platforms (stay tunned, however...). You may be required to develop with proprietary APIs for handhelds. If you'll use a browser in the handhelds, be mindful of differences in JavaScript support among browser versions and so on.
8 - Think about tag encoding. Yes, tag encoding is the kind of thing that everybody knows that exists, is well documented and so on. When it's time to develop you'll find all sorts of practical problems on how to represent tag numbers. Is it binary, decimal, hexadecimal, hexadecimal string, ASCII of the binary, LSB or MSB and so on! Then add the EPC encodings and variants and there you go: if you don't plan it well, when tag numbers flow from one place to the other there's room for problems. It may be from database to business components, or from UI to business component, or from exchange between different internal modules, or with external software. Think about your encodings in detail, and of any transformation the encodings may undergo.
9 - Don't write to the tag what you can write in the database. A few people look for writable tags and rank tags according to the space available in user memory. Avoid writting structured information to tags. I would argue: avoid writting to tags if at all possible. Begin by thinking about the business problem you are trying to solve. Then think well about the software design. Seek advice from your friends on the software design. Criticize it and so on. Only after check if you need to write to the tag. The argument for not writting structured data to the tag is scalability. What if the structure changes and you have thousands of tags deployed? Will you recall and reencode all of them? Will you do so at once or live with mixed data structures? It would become a mess. If all the business requirements need is identification of goods/objects /entities don't complicate the software. Go with just reading the tag identification.
10 - EPC-IS é um bicho de 7 cabeças complexo e distante. É como Exú Caveira: todos dizem que existe mas eu nunca vi. Um dia eu vou aprender o aperto de mão secreto e vou entender pra que server EPC-IS. De acordo com os búzios, EPC-IS é um negócio complicado e misterioso que se aplica a troca de dados entre múltiplas empresas. Só os iniciados é que entendem e podem aplicá-lo. Mas pra que sofrer desnecessariamente? Como um bom brasileiro, pense no problema que seu negócio tem e vejas as ferramentas e alternativas disponíveis. Dê um jeitinho brasileiro.
That's all for today, folks.
Happy RFID deployment!
1 - The customer often needs enterprise software for RFID. That means a solution that focuses on the business problems (and practical problems!). More often than not RFID will be just one piece of the solution. One important piece, and one piece that requires integration. But one piece among others likely. For instance, integration between the new system and ERPs or WMSs may be required. A good integrator will approach the problem aiming at a solution.
2- This is a corollary of the point above: RFID is not just about hardware. Many people spend lots of time thinking about the physics of RFID and forget (deliberately at times) about software. Good read rates is only part of the problem. (A non-problem really for software!) Middleware is a commodity now, so think of RFID hardware as any other hardware (printers, memory, hard disks, keyboard), and begin to work on how your software will address the business problems. Forget about read rates. Leave that with the hardware providers.
3- Think about the network. More specifically, the 'cloud' and the 'edge'. More generally, RFID requires software to be distributed because tagged objects are moving! Since objects go from A to B, your software needs to be in A and B. Now thinking about common roles and scenarios where RFID is deployed into, there's the 'cloud' and there's the 'edge' more often than not. RFID software in the 'cloud' is generally for managers and IT, whereas at the 'edge' is for 'warehouse workers'. This has many implications. The first direct implication is that the software gets to be partitioned: part lives at the cloud and part at the edge. While there's room for debate over what feature should live where, some restrictions apply. There's a network penalty for the edges to access the cloud. Ideally actions that require fast response or local data (data that applies to this instance of the edge) should be accessible from the edge. For instance, gadgets at the warehouse should be controlled by software at the edge and not the cloud. Reports (which require often consolidated data from all edges) are recommended to live in the cloud. Most middleware provide control for readers in a central location, so that's not a problem. Depending on the size of the deployment, you will want to think about the replication of two elements: data and rules. Depending on the location of the ERP and WMS systems you'll have data integration in the cloud. This data, however, is likely to be used at the edge. In the second case, depending on the size of deployment again, you'll want to update business rules (or new versions of software) only at the cloud and have them to migrate to the appropriate instance of the edge.
4- Time is important in RFID implementations. To begin with there are three agents that produce 'events' (there's a word that is abused): readers, software and humans. Tag reads happen and software has no control over when they happen (that is, they happen asynchronously. Well, there are synchronous tag reads. For example, tag reads triggered by handhelds are synchronous). Processes generally have two variants: those with beginning and end, and those which are 'continuous'. You may have a human beginning and ending a process, and you may have to coordinate or fit in tag reads within the (logical) process. Most software implementations will just ignore this and code everything inside the business components. And most middleware won't model the problem. (By the way, this has nothing to do with EPC-IS... initially). The best thing you can do is to think about timing issues and think about how to model processes generically. Besides the problem of coordinating time between tag reads and processes, there's always the UI. Yes, you'll have to take into account when tag reads occur and when and how to show them in the UI. With all this, try to design the software properly... (boa sorte, meu fio.)
5- Think about location and processes. Have your terms well-defined. When thinking about processes, the two variants above may convey different meaning. For instance, a tag read in the ' continuous' case may mean that the tag underwent the process (and is 'out' of the process). A tag read in a process with beginning and end may be held by the process until it's explicitly out of the process when it ends. This is specially true when there is a group of tag reads that 'enter' a process and depend on humans to exit the process. That is, it is as if tag reads are temporarily held at the process. From a business point of view the tag reads only occurred after the tags exited the process. Define a precise vocabulary with the business peers, setting what 'location' and 'process' mean.
6- Association is important. More often than not, RFID tags are attached to something. The business is usually interested in this something and not the tag itself! So think about tag associations. (One sample question to the customer: 'Are objects always associated to the same tag forever?')
7 - Think about when to use handhelds and when to use fixed readers. The primary business decision relates to labour and hardware costs. However, think about the differences for software. Mobile software is a subject that is vastly documented and explored, so there's no need for me to write too much about it. Software on handhelds must take into account network constraints (on-off connectivity, operating disconnected if needed, network latency, control of software version, manageability of software updates, etc), synchronization challenges (collecting or changing data offline), limited displays and resolutions (which requires a whole rethinking of the UI and usability), etc. Also, bear in mind that most middleware to-date are for non-mobile platforms (stay tunned, however...). You may be required to develop with proprietary APIs for handhelds. If you'll use a browser in the handhelds, be mindful of differences in JavaScript support among browser versions and so on.
8 - Think about tag encoding. Yes, tag encoding is the kind of thing that everybody knows that exists, is well documented and so on. When it's time to develop you'll find all sorts of practical problems on how to represent tag numbers. Is it binary, decimal, hexadecimal, hexadecimal string, ASCII of the binary, LSB or MSB and so on! Then add the EPC encodings and variants and there you go: if you don't plan it well, when tag numbers flow from one place to the other there's room for problems. It may be from database to business components, or from UI to business component, or from exchange between different internal modules, or with external software. Think about your encodings in detail, and of any transformation the encodings may undergo.
9 - Don't write to the tag what you can write in the database. A few people look for writable tags and rank tags according to the space available in user memory. Avoid writting structured information to tags. I would argue: avoid writting to tags if at all possible. Begin by thinking about the business problem you are trying to solve. Then think well about the software design. Seek advice from your friends on the software design. Criticize it and so on. Only after check if you need to write to the tag. The argument for not writting structured data to the tag is scalability. What if the structure changes and you have thousands of tags deployed? Will you recall and reencode all of them? Will you do so at once or live with mixed data structures? It would become a mess. If all the business requirements need is identification of goods/objects /entities don't complicate the software. Go with just reading the tag identification.
10 - EPC-IS é um bicho de 7 cabeças complexo e distante. É como Exú Caveira: todos dizem que existe mas eu nunca vi. Um dia eu vou aprender o aperto de mão secreto e vou entender pra que server EPC-IS. De acordo com os búzios, EPC-IS é um negócio complicado e misterioso que se aplica a troca de dados entre múltiplas empresas. Só os iniciados é que entendem e podem aplicá-lo. Mas pra que sofrer desnecessariamente? Como um bom brasileiro, pense no problema que seu negócio tem e vejas as ferramentas e alternativas disponíveis. Dê um jeitinho brasileiro.
That's all for today, folks.
Happy RFID deployment!
Subscribe to:
Posts (Atom)