Yet Another Focus Music generator to solve many of my problems using other services throughout the years.
What works best for me to focus is a combination of many services that exists on the market, so at the end I had to tune into many web apps on my browser which hogged my memory and I had to pay for many subscriptions making it a really expensive solution.
So I created this service, is still a work in progress, but I have been running to polish everything during this quarantine, right now I feel it is at a 90%.
I do think it matters where and how you store your data, but I really like how he puts it simple, is not a battle between to opposing sides, simply there is a need for a data store that is not that structured, it is much simplier to prototype and achieve an mvp with a NoSQL Storage, but once you are in the real world you need to provide some type of guarantee to your users, in terms of data integrity.
In my opinion everybody needs to understand the differences and use each when it is the most convenient, use the best tool for the right job.
But maybe we will start to see some type of mixup between this two systems, because as he mentions in the article, OpenSource is driving the future of the databases, and due to this, the databases of the future would be more dynamic and more synchronized to the needs of the developer.
I am really curious at how is the scene for .NET developers, with the rise of things like nw.js(node-webkit) and electron(github's atom shell).
I do know that the framework is stronger and more test proven but the traction this type of tools are earning is important.
Will the .net framework will conquer the heart of developers with the release of some of their projects as open source, and will create the best cross platform desktop development kit?
Or is it doomed to be a Windows only beutiful thing.
I worked with .NET for years and never made a desktop app. C# is a great language to work in when making backend services for websites, IMO (even though there's a whole load of crap that comes along with the framework).
These days I've moved on, but .NET is far from a desktop-only thing. Particularly when you can make iOS apps with Xamarin, etc.
>C# is a great language to work in when making backend services for websites, IMO (even though there's a whole load of crap that comes along with the framework).
Exactly how I feel. I've been working professionally with C# professionally for over a year now doing a lot of backend stuff for websites and it's great. .NET shares a similar philosophy with Python in that it's a "batteries-included" language. Need a REST endpoint? I can have one up and running from scratch in under 5 minutes with WebApi. Inter-process communication? Let me create an MSMQ instance - done! The only downside is what you mentioned - whole loads of crap that come with the framework. I hate IIS for this reason (but love how easy it is to deploy web services). We're currently working on an HTML5 replacement for our current Silverlight stack (lol) and wanted to go with Node.js instead of IIS, but we really want C# on the backend and don't want to hack it. From our point of view, JavaScript is great for the front end but completely idiotic for the amount of work we do on the backend. Type safety and static compilation is essential for us.
Others have mentioned this but they've really migrated away from an IIS-only approach. .NET 2015 has really tried to emphasize that you don't need IIS. Take a look at some of the .NET core documentation. They're officially supporting Linux and OSX when it's released (tentatively Q1 2016...so far away) but it will "just work" out of the box.
Honestly I've found getting up and running with Mono and Kestrel really simple with the latest beta. I ran from Visual Studio without really doing anything and then switched to OSX and it worked perfectly. You still need to rely on some mono classes as of now for things that haven't been open sourced (Xml streams....) but even the mono implementations worked just fine.
You don't need to use IIS for hosting anymore, look up Owin self hosting. You'll have to build some of the stuff IIS gives you yourself, but the speed is better
If you can live with the Windows only target, developing desktop apps in .NET/WPF using Visual Studio is incredibly pain free in a way that I've never found developing HTML websites. Maybe those frameworks take some of the pain away, but I can't imagine that ease of development is anywhere near that of WPF. It helps that C# is a very nice language with a really great standard library.
Yeah. The sad thing is so many web devs have never written a desktop app of any kind, so have no idea how painful the web really is. I loved Delphi in the 90's. That said, modern tools have far surpassed it.
If you want a C#+WPF type experience that's also open source and cross platform, check out Kotlin and JavaFX. JFX is the new third gen (post-Swing) GUI toolkit in Java and it's quite impressive. It's scene graph structured like WPF, has data binding, but also pays close attention to visuals: you can style it with a dialect of CSS, everything is 3D accelerated via D3D or OpenGL, you can do shader based effects on any part of the UI, etc. It has all the usual layout management and business components but also can do things like embedded h264 videos, 3D objects, and there's a tightly integrated embedded WebKit too if you need it.
Finally there's a tool that takes your app and spits out bundled/native packages for each platform, so the user doesn't ever have to know that the app was written in Java. No JRE or awful toolbars to install.
I've written a few apps this way and it's much more fun than writing a web app.
Alternatively writing web apps using Knockout seems so much nicer than WinForms and INotifyPropertyChanged hell. Maybe WPF solves this, but I wouldn't want to go back.
I was interviewing student devs recently and was flabbergasted how many of the kids doing greenfield personal projects were still using WinForms. It's frustrating how Visual Studio pushes them to work with this bone-headed warty out-of-date technology. These weren't old hands using somethign familiar just to get an MVP for a personal project, these were kids who didn't know any existing GUI frameworks and started using WinForms because it's the default in VS.
Meanwhile I am doing a greenfield project in WinForms, because it needs to be integrated into an existing eco-system of applications and components built around WinForms.
Knockout is a data binding framework for DOM/HTML based apps.
WPF and JavaFX both have a mature reactive data binding framework so altering your model causes updates to the UI and vice-versa. JavaFX has an entire functional reactive framework in it so you can build lazy functional transforms over observable collections and the like. The fact that it's an API rather than a DSL makes it kind of ugly, I believe LINQ is a little similar but much more nicely integrated for the .NET world. But it's all there.
I tried JavaFX circa 2009 and it was scary; pure black magic in terms of what the same code would on a given day. I guess Oracle put some effort into it over the years, but never, ever again will I touch that language.
It's not a custom language anymore. It's just a regular widget toolkit API like Swing. There is a thing called FXML which is a run of the mill XML based layout language, with a GUI designer called Scene Builder.
javapackager. It comes with JDK8+. It can make signed DMGs on MacOS, EXE/MSI packages on Windows, DEBs/RPMs/tarballs on Linux etc. They don't have any Java branding. Here's an example of how to use it:
The catch is you need the platform to make packages for the platform. It can't make Mac DMGs from Windows, for instance. I have a Mac laptop with Parallels so I can make packages for all three major platforms.
To stay on the .NET topic, this is the closest the JVM world currently has to something like .NET Native, I guess, although of course, there is no native code involved .... it just looks that way to the end user. I guess when .NET matures as a cross platform solution they will need a similar tool, as other platforms don't have the runtime installed by default.
I do understand that .net is far more powerfull, far more everything, but the best tool not always is the one that conquers the world. I would truthfully love to see Microsoft bring WPF to other platforms.
I love C# enough to do side projects in it, and I never thought I would say that about a msft product, especially with so many powerful scripting languages out there now. But it really is a good language, and the development environment beats any web framework toolset I have used.
In terms of desktop development, it's important to keep in mind that Windows is still what's running on ~90% of desktops and laptops outside a few bubbles. I doubt your average desktop .NET developer has spent much time thinking about those sort of cross-platform approaches, compared to how much the web has eroded the market for rich client apps.
I would disagree with that statement. Nuget packages make it incredibly easy to use other people's code in C#. You add the package, and it's ready to be referenced. Automatically pulls it in on builds, too.
Sure, I can agree with that, but that doesn't exactly impact the ease of using other people's code. The availability of said code? Definitely. The ease in which you can use it? I'd give that to C# just because of not having to download the libraries and keep them up to date yourself.
I might come across as ignorant but what is the relationship between Kubernetes and Docker, because when I was reading the article I tought of it as a Docker competitor, but further down in the comments, there is one that says they do different jobs.
Docker and Kubernetes works hand in hand. That is to say, if you choose Docker as your container format, Kubernetes runs Docker on every node to run your container. Kubernetes focuses on _what_ Docker should run, and how to move those container workloads around.
Docker also has Docker Swarm, which can be thought of as a competitor in some ways. But Google will be a heavy supporter of their container format for a long time to come.
So Kubernetes compliments Docker, but how it complements it.
I had tested Docker just for fun, thinking that maybe I could implement it in the way I work, and sure it is a super tool for developing (far better than Virtual Machines), but deploying was kind of nightmerish, for what I understood Docker wasn't at the time ready for being a deployment tool.
Does Kubernetes fixes or extends Docker in this way
Think of them as different layers. If you're a front end web dev, it's sort of like SASS vs CSS: the former is a layer on top of the latter that makes it more powerful/convenient/easier to use.
At the bottom of the stack (most low level) is the Docker runtime. It knows how to run containers on the local machine. It can link them together, manage volumes, etc but at the core it is a single machine system. (That's probably why Docker, Inc has developed their proprietary orchestration tools like swarm).
Layered on top of that are container-native OSes like CoreOS. CoreOS provides facilities for running distributed containers on multiple physical nodes. It handles things like replication and restarting failed containers (actually fleet "units"). This is a huge improvement over vanilla Docker, but it's still pretty low level. If you want to run a real production application with dependencies it can be tedious. For example, linking together containers that run on different nodes. How does container A find container B (which may be running on any one of N nodes)? To solve this you have to do things like the Ambassador Pattern[1]. Any complex application deployment involves essentially building discovery and dependency management from scratch.
Layered on top of this is Kubernetes (it runs on CoreOS but also Ubuntu and others). As said elsewhere in this post, k8s provides an opinionated workflow that allows you to build distributed application deployments without the pain of implementing things like low-level discovery. You describe your application in terms of containers, ports, and services and k8s takes care of spawning them, managing replica count (restarting/migrating if necessary) and discovery (via DNS or environment variables).
One of the very convenient things about k8s (unlike vanilla Docker) is that all containers within a pod can find each other via localhost, so you don't have to maintain tedious webs of container links. In general it takes the world of containerization from "Cool technology, but good luck migrating production over" to "I think we could do this!".
Kubernetes is a scheduler for Docker containers. So lets say you want the following:
1 x MySQL Master
2 x MySQL Slave
5 x PHP Server
1 x Monitoring Script
Each of those would be a docker container. Kubernetes would figure out which host to place them on and verify that they are running, rebooting them on another host if one of your hosts goes down.
Docker as an organization, is a competitor to Google and Kubernetes, but Docker as a tool is complemented by Kubernetes.
This is because Docker is building it's own scheduling/orchestration tools, which is what Kubernetes is for. However, as a container runtime, Kubernetes works great with Docker.
One thing I don't understand is the position of the big car makers(BMW, MB, AUDI) being a passive observer in this field.
Tesla is getting so much, that if any automaker that can deliver a car with half the specs of a model S, and keeping their model's prices as a mass produced car, would deliver a big punch to Tesla, and would greatly move the market forward.
Is it the investment necessary for building a network of charging stations?
I highly doubt it is because Tesla has more money for R&D than any other car maker.
Is getting a Model S, earns you the title of being an early adopter. Because I believe the market already shifted towards this type of vehicles, but I may be polarized, because I already desire an electric car.
I agree. Another crazy thing is that there is a shortage of Tesla-level batteries in the market right NOW. Yet aside from Tesla/Panasonic, no one else is ramping battery production to be able to produce millions of cars a year!
So when Tesla's $35k car becomes a mainstream hit in 2018, I have no doubt big auto will react with compelling competitive vehicles. The problem is they won't have the battery infrastructure in place to sell more than 50,000 units, and it'll take them several years to catch up to Tesla's production volumes!
Why do you say the other makers are passive? BMW, Mercedes, Nissan, VW, Ford and Fiat all have fully electric cars. Sure none of them get near the range the Model S does, but they are getting involved in this. A Nissan Leaf offers roughly one third the specs of a Model S, but also at one third the price. Seems like progress to me.
"Why do you say the other makers are passive? BMW, Mercedes, Nissan, VW, Ford and Fiat all have fully electric cars."
BMW has an i3 that is basically an Onion article parody version of an electric car. If you had to draw a comic of an electric car, that's what you'd draw.
They also have an absolutely ridiculous "electric" i8 that has a lawnmower engine shoehorned in it somewhere and you can listen to that fire off every now and then while you drive your luxury car around. And oh, yeah, it goes 0-60 in 4.4 seconds and they actually advertise that fact.
Mercedes also has a lame little clown car (the B-class, or whatever it is) and a bunch of "luxury" models with little chainsaw engines hidden somewhere inside. Good thing they do all that sound dampening since who wants to hear a chuggy little 3 or 4-banger fire up at every stoplight.
It's stupefying. It's flabbergasting. It defies all logic.
And it's not like it's 2002 or something and they're all reacting to the prius ... they've all had 15 fucking years to come up with something, anything that doesn't make them a joke. And they have nothing.
I don't particularly like the styling of the model S, and I really don't like the interior, and I really, really don't like a big styling void in the middle of the dash where that 17" monitor sits, but I put down a deposit and am taking delivery.
It is a spite purchase. I refuse to pay an incumbent one more cent for the privilege of enabling their anachronistic product model.
Problem with the Leaf is that a 75 mile range is unusable for most people. A 30 mile commute is pretty common, to and from work and you're almost out. Pick up kids and groceries and you'll probably be stuck on the side of the road somewhere. Forget to charge the car overnight and you're screwed.
If we take the base Model S, which has a 230 mile range, 315hp, and 0-60mph in 5.5 seconds, it goes for $70k minus $10k in tax subsidies. And compare it to the Nissan Leaf SL which has a 84 miles range, 107hp, and 0-60mph in 10.2 seconds, it goes for $35k - $7.5k in tax subsidies.
So it's exactly half the price, for much less then half the car. The Tesla has the highest safety rating out there. It handles really well. You get free charging station access. I mean, it doesn't even make sense to compare the cars. Even when you account for price, you are still getting way more than twice the car when you get the Tesla.
Progress for me would be Nissan offering a car comparable to the Model S for a comparable price.
According to Edmunds, the MSRP on the Model S 60 (the base model) is $79,570. The average price paid in my area is $79,570. I don't actually know, but I suspect Tesla does not haggle on price.
The MSRP for the Leaf is $30,585, and average price paid in my area is $25,682.
Edmunds does not account for tax subsidies. I think we can both twiddle the numbers in our favor. So the question is, what are the actual cost of ownership of these cars? I still strongly suspect, the Leaf costs roughly 1/3 of the Tesla and is roughly 1/3 of a car.
I bought a LEAF SL in Dec for $31K and change before $10K in credits. That was less than a third the cost of a Model S after rebates, IIRC.
On the downside, range is closer to 75 miles in the winter (driving normally for MA, meaning fairly fast) and a pretty regular 90-95 miles in the summer.
Overall, I love it. It's no Tesla and is not a economic winner over a good used car, but it's a damned good car and I think it's one of the most economic of the new cars, even with MA insane cost of electricity.
Saying "twice the car/half the car", like they're pints and quarts, doesn't really make sense, though.
The Nissan Leaf is intended to be a city (or at least "close in suburb") car. With my 10 mile/20 minute commute, in a city with horrible public transportation, makes the Leaf ideal. Especially since I can afford a Leaf, a Model S not so much.
With the exception of the Leaf, all those fully electric cars seem more like tests or prototypes than serious attempts to win the market. Nissan is anything but passive when it comes to fully electric cars, but all the other major car makers are being, in my opinion, overly cautious.
I just got a Fiat 500e, it is a bad ass car, and definitely doesn't feel like a test or prototype. It gets more like 85 miles (it better, it's much smaller than a Leaf), and works for almost all the transportation I need. I haven't bothered to set up a high voltage charger or anything, and I've been amazed by the convenience of it.
I agree though, they should really be pushing these electric cars. They're awesome. They're a pleasure to drive. I hate going back to gas, just shifting and the low torque are noticeable and now annoying. Maybe they just suck at advertising (doubtful) or they have other motives.
The VW e-Golf and BMW i3 are no less cars than the Leaf is. The e-Golf in particular competes directly with the Leaf, offering similar features and price. The i3 is pretty pricy, but it is a BMW after all.
I agree with you about the e-Golf. I had previously seen numbers like this: http://insideevs.com/monthly-plug-in-sales-scorecard/ that make the e-golf look like they were converting a few hundred cars to electric drivetrains as a test, but I didn't realize that the car was selling in meaningful numbers in Europe. I would love to know if they are making a profit on them or plan to in the near future. You might be right about the i3 as well, but everything about it screams "concept car" in my mind. I also consider the Volt to be a serious attempt to win the market, but it's not a fully electric vehicle.
The biggest issue at the moment is the limited range with battery only.
Even after a large network of charging stations is created, the user experience for long trips is not ideal - up to 1/4 of driving time may be spent charging.
The ownership paradigm may change at some point, but at the moment people like the idea of using their own car to go around town as well as going on vacation / see the parents / etc across the state or nation.
You are completely right, even though I would like to own a car for my daily use, and a big car for trips and etc, is not feasible, for me at least, so I have to buy the best of both worlds.
I disagree with the 1/4 of the time charging, with a solution like the Tesla's battery swap, it would be far less(I could be completely wrong in this).
Really hard for big companies to change. They have built a loyal brand around big gasoline engines. In fact the sound of the engine is so important to them that BMW pumps fake 'vroom' sounds into the i8 so it sounds like a v8. I'm not kidding.
The batteries in a Tesla aren't very green and sadly they are quite large. Big automakers think in volumes of millions of cars, Tesla delivers about 25K (EDIT: looks like 40K projected for this year[1]) cars a year.
The carbon footprint of producing the battery, even not considering the chemicals, is very large. So much so that you'd have to drive it on many years from a full-renewable source for you to break even with a regular car[1]. Tesla, sadly, maximizes the battery in their cars.
My read is that their main goal is selling batteries and everything from opening their "patents" (i.e. their custom connectors/battery pack) to the home wall-pack is designed to do that.
That doesn't really match up with the next page(8), it shows BEV beating traditional cars in both graph and quote:
"Our base case results suggest that a BEV uses the least amount of energy of all the vehicle types analyzed in this study, followed by a hybrid and a CV. The results of the CV
lifecycle analysis show that by far the greatest source of energy intensity is the use phase, at
95% of the lifecycle energy. This is due to the amounts of energy required to extract and process the gasoline and the energy intensity of the gasoline itself."
The linked report compares BEVs with ICE and Hybrid. Hybrid beats both because of the smaller battery.
BEVs have a very large upfront footprint due to the battery that needs to be paid off overtime by driving from a renewable source. However in US only 14% of energy comes from renewable sources, so it'll be a very long pay off.
Hybrids are the best way to go until we make significant strides in batteries (20-30 years off?). You rely on your charged battery for most of your trips, and the highly optimized gas engine kicks in when you need the extra range/juice.
I didn't. He is talking about the footprint of the fuel (electricity vs gasoline). The report addresses that as well. It looks at OVERALL footprint of the three different types, and includes upfront cost (i.e. production which includes battery) and on-going.
Larger battery means a much larger up-front carbon footprint. Unfortunately on an on-going basis due to profile of electricity production in US you are burning a ton of coal [1] to generate that electricity. Coal is far, far worse than gas in the carbon impact as well as extraction footprint.
Because of the much larger initial hole you've dug (due to a very, very large battery) you're not going to crawl your way out of this deficit for a long time.
The logical solution is to minimize the battery to a degree that it would cover most weekday commutes (which isn't 300 some-odd miles). You would have a much smaller, optimized, gas based generator to recharge that battery for the odd time the person needs the longer range.
It gives you the best of both worlds. You would get far greater savings. This is the reason why other manufacturers are making hybrids or if they do make pure EV it has a much smaller battery than Tesla.
Not sure if these are correct figures, but http://www.goodcarbadcar.net/2015/01/usa-minivan-sales-figur... says the Chrysler Town & Country sold 138k, and the Dodge Caravan sold 134k, this appears to be US only data; and these two vehicles are really the same vehicle with different trim, so that's about 10 times the number of Tesla vehicles.
Isn't it an overstatement that the batteries aren't green? Yes, there are environmental impacts from the production, but still a lot less than the environmental impacts of all the oil that would otherwise be produced and burnt to fuel the car over its lifetime, no?
But, isn't the lifetime of the battery pack significantly lower than the (presumed) lifetime of the actual car? If your Model S stays on the road 20 years but requires 3-4 battery replacements, that's several big hits against its environmental friendliness.
The lifetime of the battery will likely be much longer than it's life in the car - if the plans for 'second life' re-use as static energy storage devices come to pass.
The lifetimes of battery packs have been greatly underestimated by detractors for quite some time. Hybrids have been on the US market since 1999, and battery life has never been a serious issue. The new batteries are far higher quality than the old ones anyway.
3-4 battery replacements over 20 years isn't anything close to what a Model S will require. Do you have a source for those figures?
That's my understanding, but it's important to keep this in mind when touting the merits of battery tech. Of course, the battery production and charging process can become drastically more green (and will do so once the Gigafactory is operational), so even this is somewhat of a moot point.
According to Tesla's own statements, they are planning to deliver 55k this year, and their Q2 deliveries of 11,507 puts them on track (by their own estimates). I would assume some of those deliveries will be for the Model X, which is supposed to start shipping in Q3. Source: http://www.businessinsider.com/tesla-sets-a-new-record-for-c...
This is like saying that the Formula 1, exists for nothing. This is the way to test all the engineering efforts, it also leaves that knowledge in the company for future and further improvements, which directly influences the design and execution of the Model 3.
But I have to agree that waiting for an affordable Tesla car is getting anoying, and they do need to create an income stream from a lower priced model for creating a sustainable company, and take advantage of the wow factor that still surrounds Tesla and evertything they make.
But they have also innovated in other areas like the house batteries, which for me was a surprise (for me it seems odd that Tesla makes batteries for the average household) but they are generating other income streams, so it seems that Teslas agenda is not only the Model 3.
As a fellow F1 buff, the upgrades takes years to roll down to production cars. And in software parlance, they shouldn't be focusing on the MVP at this point.
they have also innovated in other areas like the house batteries
That right and that may be more profitable and they may pivot and leave the car manufacturing to the incumbents.
I disagree. Twisted is a sprawling codebase, it started as a game library that turned into an async library along the way, you need to read books to get the full documentation, and some of it doesn't even have docstrings or comments.
You are right it is not the best example of an open source project, and for what you say it neither is a good python project example. But is there any other place you can get the hold of working async with python, it may be hard, but you would learn a lot.
But maybe there are other async python projects that I don't know of. If you know of any please post them, I would also like to learn more about the subject.
What I am struggling with, is the use case of a library like this.
Is this oriented towards gaming or substitude something like d3.js or is it has a simplier api, for the developer than other libraries. Or is it a library to showcase the cool stuff that can be done with new technologies.
I think the main difference and the selling point is that it is "renderer agnostic" but I don't understand the benefits of that.
Renderer-agnostic is nice, actually, when you need to support lots of different browsers.
Some mobile browsers can't do WebGL as fast as they do Canvas, for instance. Other browsers will have a huge speed advantage with WebGL.
I'm not sure if any are faster with SVG, or the relative performance between SVG and canvas. But being able to do some test renders quickly in all three modes should allow you to select the fastest for a particular browser.
Game developers are better off with a game-oriented library, IMO. Even if you used something like Two.JS to do your rendering, there are a lot of things still useful in a game library to justify using it -- and most games will need more than geometric figures.
I love SVG support because it means you can render something in vector art in the browser which is also downloadable as a file by the user. Drawing stuff in the browser which is then stuck there is cute but lacks an important layer of interoperability with the rest of the computing ecosystem. So here we appear to get the best of all worlds: render to whatever is fastest in the browser but get automatic "export as SVG" for free.
I don't know what the real use case is, but I know that it's been awesome as a simple graphics API to teach programming to kids.
A while back I used Choc (http://www.fullstack.io/choc/) to teach JavaScript to a high school class. A lot of Two's competitors have APIs that take into account things like performance and extensibility, but are harder to explain because of it. It was great to have a simple API that got out of the way and allowed me to teach things like if statements, for loops and functions.
The author of two.js uses it for interactive art, like Patatap. It's great for creating fun motion design easily. I worked with him on a project where a live drummer plays drums and triggers sounds and shapes projected behind him: http://thecreatorsproject.vice.com/blog/introducing-drumpant...
It would be good if you wanted to make some content that has smooth animations that renders in all different browsers (i.e animated greeting cards, animated presentations, or animated websites). Basically anything that you could do in Flash 2D, you could also do with this.
Example: makemake.io (although PIXI.js is used in this case)
But how do you become a good data scientist, instead of a technical person, that knows how to apply an algorithm in Python/R.
What I am trying to ask is how do you become good at setting your start point(formulate your hypotheses), communicating your insights and selecting which tools apply where, because if your are good at coding and have experience in things related to computer science you have the abilities to handle a dataset(SQL Knowledge) and the data tools(Python, Pandas, etc), but that doesn't earn you the title of data scientist.
Practice. And education, but mostly practice. This is the kind of thing that is typically taught in formal educational settings (at least in engineering, which is my experience). As an example, I learned more about probability & statistics in 1) AP biology in high school, and 2) a "simulation systems" class in my industrial engineering master's curriculum. We spent much of the former class learning basic statistical analysis techniques (ANOVA, chi-square, etc) to apply to our lab data, and the latter class was all about statistical analysis of process flows (aimed at the real life problem of factory production planning & scheduling and manufacturing process optimization).
So, do I consider myself a data scientist? Absolutely not. But do I understand basic statistical concepts and know how to apply them to several categories of real life data analysis problems.
Would you recommend any approach or I should go undust my high school and college books in the search for study material. Or is this too basic material.
