Blog

Into the Aquaria Rabbit Hole

I have been intrigued by aquaria (plural of aquarium) for a while, and more specifically, really interested in the last year.

When I was an adolescent, my step-father had a freshwater fish tank with tetras, and I thought they were interesting enough, but only mildly so. Perhaps because of their tiny size of a couple of inches long and mediocre colors, I didn’t feel like they were captivating enough to warrant my time.

In a passing comment, I think I asked my parents, “Hey, why not get a saltwater tank! Those seem more interesting!” But my parents dismissed it rather quickly, and perhaps because I wasn’t interested enough in the tank we did have, I didn’t really press further. I instead focused on girls, which were way more fun at that time anyway.

Fast forward 20 years later. Last year, I discovered that a co-worker had some decent experience with saltwater aquaria and had educated himself on the topic rather well. In casual conversation, my curiosity resurrected and I started asking a lot of questions and learning quite a bit – enough to whet my appetite to start looking into the hobby more seriously this time around.

After only minimal research, I quickly realized that, given my age back then, there is simply no way I had the maturity or patience to be able to keep a saltwater tank alive. Saltwater tanks, if you don’t give them the time and attention they deserve, are difficult to maintain. Really difficult. And, as any experienced saltwater aquarist will tell you, they will inevitably become a money sink if you’re not cautious. Definitely not a hobby for a free-willed teenager with a part-time minimum wage job!

But I’ve learned recently that saltwater tanks can be an amazing hobby, and well worth the effort, especially if you enjoy any of the scientific or engineering disciplines. I don’t think I’ve found any hobby that more completely exposes the practitioner to science and engineering in a more fulfilling way. Saltwater aquarists learn more than a cursory amount of at least the following disciplines:

  • Physics: fluid dynamics, pressure, optics, gravity, electromagnetism, and more.
  • Engineering: pump mechanics, flow/pipe construction and building, overflow design, fault-tolerance, lighting design, environmental control systems and systems automation.
  • Construction: if you enjoy DIY, you can make your own tank, the stand it rests on, bracing and sub-systems used to keep the tank alive. If you’re a woodworker, you’ll have a big advantage here.
  • Chemistry: an applied knowledge of the Nitrogen Cycle, reverse osmosis and de-ionization, and knowing how to test for and control calcium, phosphate, magnesium, strontium, iodine, carbon, salinity control, and more.
  • Biology: this one is obvious, but it goes well beyond fish. Aquarists can gain deep understanding of corals, crustaceans, algae, bacteria and parasites, and more. Many aquarists can spout off Latin names and genus classifications like nothing.
  • Ecology: understanding environmental balance, both within a tank, and how it helps you understand the real world (and what we humans do to it) in a way that most people will never be able to understand (other than scientists actually employed to do so).
  • Design: a fun part of saltwater aquaria is aquascaping, where you can design beautiful in-tank landscapes with rock, corals and zoantharia (see? biology!) that can help relax and calm anyone.

Think about this for a second. If you like the Discovery Channel or National Geographic or the Science Channel, you might find saltwater aquaria far more enjoyable and rewarding than the shows on those channels. And let’s face it, Discovery Networks should just be ashamed at the completely false “scientific” crap they spew on some of their shows (Pawn Stars on the History Channel? Is that how low we have become as a nation? Anyway, I digress…). Have a saltwater aquarium, and you’ll be rewarded with first-hand knowledge with real scientific experience. You’ll probably now more than Discovery Networks’ producers anyway.

Anyway, I have been researching how to start my own saltwater aquarium for almost an entire year, without so much as buying a single piece of equipment. If you’re thinking of becoming an aquarist, don’t let this discourage you however; I’m just a little too OCD when it comes to trying anything complicated of which I have little initial knowledge. It is just my personality to want to become relatively knowledgeable in something before I invest real money into a potentially challenging venture. Plus, I just like the process of learning a lot, so the research is probably as fun to me as actually building something. I also like reading as much as I can to ensure that I don’t make silly mistakes, and I benefit a lot from reading from others’ mistakes so I can (hopefully) not repeat them.

That being said, most people start in the hobby with far less preparation, and most are just fine, especially with online help from the ReefCentral Forums (I’m kendoka there – say hi!).

So, as you can see, with so much to learn, saltwater aquaria can be a definite rabbit hole, but for me, and I assume many like me, this is actually part of the appeal of the hobby.

Learning and then applying knowledge to create something truly beautiful and personally rewarding sounds like something right up my alley. I jumped down the rabbit hole last year, and I’m enjoying the journey so far!

Posted in Blogroll

AeroGear 1.4.0 Released

AeroGear Android 1.4

Today we have pushed to Maven Central our the AeroGear’s Android library version 1.4. Major features include 1) The Authorizer framework with OAuth2 support 2) enhanced Request and Response handlers for Pipe’s 3) a dedicated Push messaging module 4) updated docs and sample applications and 5) full aar support for Android Studio. See the New Feature Showcase section for more details.

Fetching is as easy as always:

Fetch with Maven

<dependency>
    <groupId>org.jboss.aerogear</groupId>
    <artifactId>aerogear-android</artifactId>
    <type>apklib</type>
    <version>1.4.0</version>
</dependency>

Fetch with Gradle

compile 'org.jboss.aerogear:aerogear-android:1.4.0@aar'

Clone and import the project with Eclipse and ADT

git clone https://github.com/aerogear/aerogear-android
cd aerogear-android
git checkout tags/1.4.0
mvn dependency:copy

New Feature Showcase

Oauth2

This is perhaps the biggest change and deserving of a blog post of its own. In the meanwhile, you can view our sample app.

Request / Response Handler improvements

An example of the improved APIs can be found in our cookbook.

Push Module

Our push module is on GitHub with a sample application in our quickstart. The module is also available in Maven Central.

What’s Next

Our next version of Android will be focused on core API improvements. Specifically we will continue our modularization efforts, remove deprecated methods, and switch from using a Callback style API to using a Promise/Future style API. This release will also mark the beginning of our 2.0 branch.

Additional features will be included as modules. Currently we are planning for or working on the following :

  • aerogear-android-sync
  • aerogear-android-offline
  • aerogear-android-simplepush

Once our planning is finalized, details will be published on our roadmap.

Follow us on Twitter @aerogears, on freenode #aerogear, on the web www.aerogear.org, on GitHub https://github.com/aerogear or subscribe to our mailing list aerogear-dev@lists.jboss.org.

Posted in Blogroll

Edoardo Vacchi on attribute grammars

I previously wrote that predictable performance is a practical challenge for using attribute grammars on real work. It does little good to quickly write the first version of a compiler pass if you then spend hours debugging oddball performance problems.

Edoardo Vacchi wrote me the following in response. I agree with him: having an explicit evaluation construct, rather than triggering attribute contributions automatically, is likely to make performance more predictable. UPDATED: edited the first paragraph as suggested by Edoardo.

Hi,

This is Edoardo Vacchi from Università degli Studi di Milano (Italy). For my PhD thesis I’m working on a language development framework called “Neverlang”[1,2]. Neverlang is an ongoing project of Walter Cazzola's ADAPT Lab; I am involved with its latest incarnation "Neverlang 2".

I stumbled upon an (old) blog post of yours about Attribute Grammars [3] and I would be interested to know if you knew some “authoritative” references that I could cite with respect to the points that you raise, with particular attention to point (3) “unpredictable performances” and, in part, to (2) caching.

The Neverlang model resembles that of simple “compiler-compilers” like Yacc, where attributes behave more like variables than functions; thus they are generally computed only once; in Neverlang attributes can also be re-computed using the `eval` construct, which descends into a child and re-evaluates the corresponding semantic action.

On the one hand, the need for an explicit `eval` make it less “convenient” than regular AG-based frameworks; on the other hand, I believe this gives better predictability, and, although the focus for the framework are not performances, but rather modularity, I think that “predictability” would better motivate the reasons for this choice.

Thanks in advance,

[1] http://link.springer.com/chapter/10.1007%2F978-3-642-39614-4_2#page-1
[2] http://dl.acm.org/citation.cfm?id=2584478
[3] http://blog.lexspoon.org/2011/04/practical-challenges-for-attribute.html

Edoardo Vacchi is PhD Student at Walter Cazzola's ADAPT-Lab, a research lab at Università degli Studi di Milano that investigates methods and techniques for programming language development and software adaptation and evolution. Walter Cazzola is associate professor at UniMi and his research is concerned with software and language engineering. More info about Neverlang can be found at the website http://neverlang.di.unimi.it.
Posted in Blogroll

Edoardo Vacchi on attribute grammars

I previously wrote that predictable performance is a practical challenge for using attribute grammars on real work. It does little good to quickly write the first version of a compiler pass if you then spend hours debugging oddball performance problems.

Edoardo Vacchi wrote me the following in response. I agree with him: having an explicit evaluation construct, rather than triggering attribute contributions automatically, is likely to make performance more predictable. UPDATED: edited the first paragraph as suggested by Edoardo.

Hi,

This is Edoardo Vacchi from Università degli Studi di Milano (Italy). For my PhD thesis I’m working on a language development framework called “Neverlang”[1,2]. Neverlang is an ongoing project of Walter Cazzola's ADAPT Lab; I am involved with its latest incarnation "Neverlang 2".

I stumbled upon an (old) blog post of yours about Attribute Grammars [3] and I would be interested to know if you knew some “authoritative” references that I could cite with respect to the points that you raise, with particular attention to point (3) “unpredictable performances” and, in part, to (2) caching.

The Neverlang model resembles that of simple “compiler-compilers” like Yacc, where attributes behave more like variables than functions; thus they are generally computed only once; in Neverlang attributes can also be re-computed using the `eval` construct, which descends into a child and re-evaluates the corresponding semantic action.

On the one hand, the need for an explicit `eval` make it less “convenient” than regular AG-based frameworks; on the other hand, I believe this gives better predictability, and, although the focus for the framework are not performances, but rather modularity, I think that “predictability” would better motivate the reasons for this choice.

Thanks in advance,

[1] http://link.springer.com/chapter/10.1007%2F978-3-642-39614-4_2#page-1
[2] http://dl.acm.org/citation.cfm?id=2584478
[3] http://blog.lexspoon.org/2011/04/practical-challenges-for-attribute.html

Edoardo Vacchi is PhD Student at Walter Cazzola's ADAPT-Lab, a research lab at Università degli Studi di Milano that investigates methods and techniques for programming language development and software adaptation and evolution. Walter Cazzola is associate professor at UniMi and his research is concerned with software and language engineering. More info about Neverlang can be found at the website http://neverlang.di.unimi.it.
Posted in Blogroll

My analysis of the Swift language

Apple has put out Swift, which sounds like a nice language overall. Here is my flagrantly non-humble opinion about how its features line up with what I consider modern, well-established aspects of programming language design.

The good

First off, Swift includes range-checked integer arithmetic! Unless you explicitly ask for wraparound, any overflow will cause an exception. I was just commenting yesterday on what a tough problem this is for current programming languages.

It has function types, nested functions, and closures, and it has numerous forms of optimized syntax for closures. This is all heartening, and I hope it will stick going forward, much the way lexical variable binding has stuck. Closures are one of those things that are both helpful and have small down side once your language has garbage collection.

Swift's closures can assign to variables in an outer scope. That's the right way to do things, and I find it painful how much Java's designers struggle with this issue. As a technical detail, I am unclear what happens if a closure captures a variable but does not modify it. What ought to happen is that any read from it will see the latest value, not the value at the time the capture happened. However, the Closures section of the Language Guide suggests that the compiler will capture just the initial value in this case. I believe this is misguided and will cause as many traps as it fixes; for example, suppose the programmer captured a counter, but does not increment that counter itself? The motto here should be: you don't know what the programmer meant, but you know what they wrote.

Type inference is quite welcome. I don't know what more to say than that developers will take advantage of it all the time, especially for local variables.

Tuple types are a small touch that comes up in practical programming all the time. How many times have you wanted to return two values from a function, and had to design a class for it or otherwise to pervert your design?

Enumerations seem good to include in the language. Language designers often seem to think that enums are already handled by other language features, and therefore should not be included. I respect that, but in this case, it's a simple feature that programmers really like to use. Java's enums are baroque, and none of the several Datalog dialects I have wokred on include enums at all. I miss having language support for a closed set of named integers. It's easy to support and will be extremely popular.

As an interesting trick, keyword arguments to functions are supported, but you have to opt in. That's probably a good combination. Keyword arguments are quite useful in cases where you have a lot of parameters, and sometimes this legitimately happens. However, it's unfortunate if you afflict all functions with keyword arguments, because the keyword arguments become part of the API. By making it opt in, the feature is there for the functions which can use it.

Including both structs and classes looks initially redundant, but it's quite helpful to have a value type that encompasses multiple other values. As an example, the boxed Integer type on Java would be much better as a struct than as a class.

Extensions look valuable for programming in the large. They allow you can make an existing class fit into a new framework, and they let you add convenience methods to an existing class. Scala uses its implicit conversions for extensions, but direct support for extensions also makes a lot of sense.

The way option chaining works is a nice improvement on Objective C. In Objective C, any access to nil returns nil. In practice, programmers are likely better off with getting an error when they access nil, as a form of design by contract: when something goes wrong, you want the program to stop at that point, not some indefinite time later. Still, sometimes you want nil propagation, and when you do, Swift lets you just put a "?" after the access.

Weak references are helpful for any language with automatic memory management, but they look especially helpful in a language with reference-counting memory management. I don't follow why there are also the "unowned" references, except that the designers didn't want your code to get polluted with ! dereferences. Even so, I would think this is a case of do or do not do. If you are worried about ! pollution, which is a legitimate concern, then simply don't require the !.

As an aside, this is the reason I am not sure pervasive null is as bad as often claimed. In practical code, there are a lot of cases where a value is sometimes optional but, in a specific context, is known to be present. In such a case, you are just going to deference it, and possibly suffer a null-pointer check if you were wrong. As such, programmers are guided into a style where they just insert dereferences until the compiler shuts up, which makes the code noisey without increasing practical reliability.

The dubious

Swift looks very practical and workable, but there are some issues I think could have been done better.

Single inheritance seems like a step backward. The linearization style of multiple inheritance has proven helpful in practice, and it eliminates the need for a separate "interface" or "protocol" feature. Perhaps designers feel like C++'s multiple inheritance went badly, and are avoiding multiple inheritance like the plague? I used to think that way, but it's been multiple decades since C++'s core design. There are better design for multiple inheritance nowadays.

Swift doesn't appear to include persistent data structures. This is the one feature I miss the most when I don't get to program in Scala, and I don't know why it isn't catching on more widely in other languages. Developers can add their own collection types, but since the new types aren't standard, you end up having to convert to standard types whenever you call into another library.

The automatic immutability of collections assigned to constants looks driven by the lack of persistent collections. It's better to support both features independently: let variables be either mutable or not, and let collections be mutable or not. All four combinations are very useful.

Deinitialization, also known as finalization, looks like a throwback to me. In a system with automatic memory management, you don't want to know precisely when your memory is going to get freed. As such, you can't count on deinitializers running soon enough to be useful. Thus, you always need a fallback plan of deallocating things manually. Once you deallocate manually, though, deinitializers become just a debugging technique. It's better to debug leaks using a tool than with a language feature.

In-out parameters seem like a step backwards. The trouble is that most functions use only in parameters, so when you see a function call, a programmer's default assumption is that the callee will not modify the argument. It can lead to bad surprises if the parameter gets modified at all. Out parameters are so unusual that it's better to be explicit about them, for example by taking a mutable collection as an argument.

Custom precedence (and associativity) is likely to go badly. We discussed this in detail, over the course of days, for X10, because X10 is a scientific language that really benefits from a rich set of operators. One problem with user-defined precedence is that it's hard to scope: you want to scope the operators themselves, not their implementations, because parsing happens before method lookup. It's also tough on programmers if they have to learn a new precedence table for every file of code they read. All in all, we concluded that Scala had a reasonable set of trade offs here: have a built-in precedence table with a huge number of available operators, and make library designers simply choose from the existing operators.

I see no exceptions, which is likely to be a nuisance to programmers if they are truly missing. Sometimes you want to tear down a whole chunk of computation without exiting the whole program. In such cases, exceptions work very well. Maybe I just missed it.

Integer types are hard to get right, and I am not sure Swift has chosen a great approach. It's best to avoid unsigned types, and instead to have untyped operations that can apply to typed integers. It's also best to avoid having low-precision operations, even if you have low-precision storage. Given all of the above, you don't really need explicit conversions any more. Java's integer design is quite good, with the exception of the unnecessary char type that is not even good for holding characters. I suspect many people overlook this about Java, because it's a case where programmers are better off with a language with fewer features.

Posted in Blogroll

My analysis of the Swift language

Apple has put out Swift, which sounds like a nice language overall. Here is my flagrantly non-humble opinion about how its features line up with what I consider modern, well-established aspects of programming language design.

The good

First off, Swift includes range-checked integer arithmetic! Unless you explicitly ask for wraparound, any overflow will cause an exception. I was just commenting yesterday on what a tough problem this is for current programming languages.

It has function types, nested functions, and closures, and it has numerous forms of optimized syntax for closures. This is all heartening, and I hope it will stick going forward, much the way lexical variable binding has stuck. Closures are one of those things that are both helpful and have small down side once your language has garbage collection.

Swift's closures can assign to variables in an outer scope. That's the right way to do things, and I find it painful how much Java's designers struggle with this issue. As a technical detail, I am unclear what happens if a closure captures a variable but does not modify it. What ought to happen is that any read from it will see the latest value, not the value at the time the capture happened. However, the Closures section of the Language Guide suggests that the compiler will capture just the initial value in this case. I believe this is misguided and will cause as many traps as it fixes; for example, suppose the programmer captured a counter, but does not increment that counter itself? The motto here should be: you don't know what the programmer meant, but you know what they wrote.

Type inference is quite welcome. I don't know what more to say than that developers will take advantage of it all the time, especially for local variables.

Tuple types are a small touch that comes up in practical programming all the time. How many times have you wanted to return two values from a function, and had to design a class for it or otherwise to pervert your design?

Enumerations seem good to include in the language. Language designers often seem to think that enums are already handled by other language features, and therefore should not be included. I respect that, but in this case, it's a simple feature that programmers really like to use. Java's enums are baroque, and none of the several Datalog dialects I have wokred on include enums at all. I miss having language support for a closed set of named integers. It's easy to support and will be extremely popular.

As an interesting trick, keyword arguments to functions are supported, but you have to opt in. That's probably a good combination. Keyword arguments are quite useful in cases where you have a lot of parameters, and sometimes this legitimately happens. However, it's unfortunate if you afflict all functions with keyword arguments, because the keyword arguments become part of the API. By making it opt in, the feature is there for the functions which can use it.

Including both structs and classes looks initially redundant, but it's quite helpful to have a value type that encompasses multiple other values. As an example, the boxed Integer type on Java would be much better as a struct than as a class.

Extensions look valuable for programming in the large. They allow you can make an existing class fit into a new framework, and they let you add convenience methods to an existing class. Scala uses its implicit conversions for extensions, but direct support for extensions also makes a lot of sense.

The way option chaining works is a nice improvement on Objective C. In Objective C, any access to nil returns nil. In practice, programmers are likely better off with getting an error when they access nil, as a form of design by contract: when something goes wrong, you want the program to stop at that point, not some indefinite time later. Still, sometimes you want nil propagation, and when you do, Swift lets you just put a "?" after the access.

Weak references are helpful for any language with automatic memory management, but they look especially helpful in a language with reference-counting memory management. I don't follow why there are also the "unowned" references, except that the designers didn't want your code to get polluted with ! dereferences. Even so, I would think this is a case of do or do not do. If you are worried about ! pollution, which is a legitimate concern, then simply don't require the !.

As an aside, this is the reason I am not sure pervasive null is as bad as often claimed. In practical code, there are a lot of cases where a value is sometimes optional but, in a specific context, is known to be present. In such a case, you are just going to deference it, and possibly suffer a null-pointer check if you were wrong. As such, programmers are guided into a style where they just insert dereferences until the compiler shuts up, which makes the code noisey without increasing practical reliability.

The dubious

Swift looks very practical and workable, but there are some issues I think could have been done better.

Single inheritance seems like a step backward. The linearization style of multiple inheritance has proven helpful in practice, and it eliminates the need for a separate "interface" or "protocol" feature. Perhaps designers feel like C++'s multiple inheritance went badly, and are avoiding multiple inheritance like the plague? I used to think that way, but it's been multiple decades since C++'s core design. There are better design for multiple inheritance nowadays.

Swift doesn't appear to include persistent data structures. This is the one feature I miss the most when I don't get to program in Scala, and I don't know why it isn't catching on more widely in other languages. Developers can add their own collection types, but since the new types aren't standard, you end up having to convert to standard types whenever you call into another library.

The automatic immutability of collections assigned to constants looks driven by the lack of persistent collections. It's better to support both features independently: let variables be either mutable or not, and let collections be mutable or not. All four combinations are very useful.

Deinitialization, also known as finalization, looks like a throwback to me. In a system with automatic memory management, you don't want to know precisely when your memory is going to get freed. As such, you can't count on deinitializers running soon enough to be useful. Thus, you always need a fallback plan of deallocating things manually. Once you deallocate manually, though, deinitializers become just a debugging technique. It's better to debug leaks using a tool than with a language feature.

In-out parameters seem like a step backwards. The trouble is that most functions use only in parameters, so when you see a function call, a programmer's default assumption is that the callee will not modify the argument. It can lead to bad surprises if the parameter gets modified at all. Out parameters are so unusual that it's better to be explicit about them, for example by taking a mutable collection as an argument.

Custom precedence (and associativity) is likely to go badly. We discussed this in detail, over the course of days, for X10, because X10 is a scientific language that really benefits from a rich set of operators. One problem with user-defined precedence is that it's hard to scope: you want to scope the operators themselves, not their implementations, because parsing happens before method lookup. It's also tough on programmers if they have to learn a new precedence table for every file of code they read. All in all, we concluded that Scala had a reasonable set of trade offs here: have a built-in precedence table with a huge number of available operators, and make library designers simply choose from the existing operators.

I see no exceptions, which is likely to be a nuisance to programmers if they are truly missing. Sometimes you want to tear down a whole chunk of computation without exiting the whole program. In such cases, exceptions work very well. Maybe I just missed it.

Integer types are hard to get right, and I am not sure Swift has chosen a great approach. It's best to avoid unsigned types, and instead to have untyped operations that can apply to typed integers. It's also best to avoid having low-precision operations, even if you have low-precision storage. Given all of the above, you don't really need explicit conversions any more. Java's integer design is quite good, with the exception of the unnecessary char type that is not even good for holding characters. I suspect many people overlook this about Java, because it's a case where programmers are better off with a language with fewer features.

Posted in Blogroll

Rails 4 MiniTest error

I got the following cryptic error on a new project:

~/…/unit.rb:1037:in `block in process_args’: invalid option: —use-color (OptionParser::InvalidOption)

Thanks to this blog for pointing the way.

I did not copy/paste the suggested code though.  I just ran :

guard init minitest

Posted in Blogroll

Rails 4 MiniTest error

I got the following cryptic error on a new project:

~/…/unit.rb:1037:in `block in process_args’: invalid option: —use-color (OptionParser::InvalidOption)

Thanks to this blog for pointing the way.

I did not copy/paste the suggested code though.  I just ran :

guard init minitest

Posted in Blogroll

Strange Bundler error, noexec.rb:5:in `pwd’

I got the following after running "bundle install" :
rubygems-bundler-1.4.2/lib/rubygems-bundler/noexec.rb:5:in `pwd': No such file or directory - getcwd (Errno::ENOENT)

Thanks to stackoverflow and this blog I cd'd into the parent directory and then back into my working directory and bundler worked.
Posted in Blogroll

Strange Bundler error, noexec.rb:5:in `pwd’

I got the following after running "bundle install" :
rubygems-bundler-1.4.2/lib/rubygems-bundler/noexec.rb:5:in `pwd': No such file or directory - getcwd (Errno::ENOENT)

Thanks to stackoverflow and this blog I cd'd into the parent directory and then back into my working directory and bundler worked.
Posted in Blogroll

AJUG Tweets

Follow @atlantajug on twitter.

AJUG Meetup

Large-scale Entity Extraction and Probabilistic Record Linkage

Tuesday, August 19, 2014

Large-scale entity extraction, disambiguation and linkage in Big Data can challenge the traditional methodologies developed over the last three decades. Entity linkage, in particular, is cornerstone for a wide spectrum of applications, such as Master Data Management, Data Warehousing, Social Graph Analytics, Fraud Detection and Identity Management. Traditional rules based heuristic methods usually don’t scale properly, are language specific and require significant maintenance over time.

We will introduce the audience to the use of probabilistic record linkage, also known as specificity based linkage, on Big Data, to perform language independent large-scale entity extraction, resolution and linkage across diverse sources. We will also present a live demonstration reviewing the different steps required during the data integration process (ingestion, profiling, parsing, cleansing, standardization and normalization), and show the basic concepts behind probabilistic record linkage on a real-world application.

Location:


Holiday Inn Atlanta-Perimeter/Dunwoody

4386 Chamblee Dunwoody Road,
Atlanta, GA (map)