Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
alright hi everybody I am Coraline 8am key I work at apartments calm we're hiring I'm a principal developer there and like our previous speaker I did not have a CS degree in fact I'm a college dropout but I'm an autodidact which means that
I know the word autodidact basically I taught myself everything that I care about um one more thing I'm from Chicago and there are no fewer than five quarries in Chicago who do Ruby I'm the one with the fuchsia hair just all right so what is business
intelligence what do I mean by it this is what we're going to be talking about today basically the stages of adoption to business intelligence whether or not we can build it ourselves and whether we should build it ourselves so of course I have to start
with the definition right so business intelligence means taking mission critical knowledge inside of your company organizing it to provide a historical perspective and using it for real-time decision making it sounds pretty straightforward it's reporting
essentially sometimes it's called data science sometimes it's called data warehousing and they're all sorts of names for it in the end it's about taking the data that is essential to running your company making sure it's accessible to the
people who need it and putting it in a form that's going to support the business actually making decisions moving forward I like to talk about the three pillars of Technology supporting business technology was in business we're not always partners
and we sort of take for granted now a software developer said if you're a company of course you have a development team and of course you have all these other things so I think there are three main parts of how technology supports business versus infrastructure
and this is everyone everything from the iron that the applications are running on to the accounting system the HR system all the stuff that I'm really bored by the second sort of pillar is applications and as developers this is where we spend most of
our time we enjoy writing applications we're delivering business value the applications we're letting the business scale hopefully through the applications we create retracting customers by the applications we create and the third tier is data data
to a developer is often an afterthought we use our data stores to store objects that we need in our applications and once we're done with those objects we're kind of done with thinking about the data maybe you have a report that you have to build for
the accounting team or something like that but again once it's built your kind of done with it and you're working off their requirements so this this is recognized as a sort of flaw in sort of a week pillar a lot of a lot of times especially as a business
gets larger so typically the business will want to address how to collect how to use the massive amount of data that's been built up and how to actually turn it into an asset for them when developers make friends with data though Fluttershy gets your cutie
mark which is a MongoDB cutie mark by the way and friendship is magic damn it so I want to talk about how you actually go about adopting business intelligence systems and I'm going to do it in three acts this is typically the first two acts are typically
how most companies do it and unfortunately they stopped after the second act throw up their hands in despair and you know wander off in the distance looking for enlightenment the third phase is the one that I'm proposing that I hope that all of you will
go forward and build so this is a Fiji mermaid I don't know if you're familiar with this in the late nineteenth and early twentieth centuries there were a lot of traveling traveling sideshows and circus shows and the feejee mermaid was basically the
torso of a monkey sewn onto the body of the tail of a fish and there were some paper mache does sort of make the transition kind of smooth and the legend was that it was caught by a fisherman in Fiji and now it's like on display for everyone to see and
a lot of people believed in it so if you're the kind of person who believes in the feejee mermaid you're probably also the person who thinks you can report straight out of your transactional database everyone has done this at some point in time don't
feel embarrassed about it I have done it many many times I'm not going to ask you to embarrass yourselves by raising your hands but I know you're out there so what happens when you do this our data stores are transactional data stores are built for
what they call transactions so we have we have a lot of like distinct tables hopefully you're not doing single table inheritance distinct tables for each of our objects there are complex relationships between them maybe join tables maybe join models and
when it comes time to report off of those you get some really really gnarly sequel which brings with it performance issues and this is something that one of the workshops is actually talking about a little later you might want to check into that and to get
around the performance issues you decide I can write better sequel an arrow can good luck what you find is that when you're doing reporting you're impacting your production resources your servers will get slow so you're like I guess we better only
[ ... ]
Nota: se han omitido las otras 2.659 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.