1,017 karma · joined March 6, 2016
A related note is for any requirements files. Something like this bit me the other day.
Libraryname >=3.1
After a few years,the package was updated substantially and has lots of breaking changes in the recent branch. Fix was to so ==3.1 until we work out the next step
def write_report():
db = connect_to_database()
data = get_data(db)
summary = summarise_data(data)
save_report(summary)
After this, do the same for each of these functions.As you said though, its a simple test, and if you don't think about it too much, its too easy to just test the email ends in .edu and move onto the next task.
The problem is when you are just "on the phone", not really doing anything, not anything you planned to do, and not really getting anything done. Even this can be fine, as long as you go "I'd like to see whats on twitter for half an hour", rather than just opening things up and doing them because the algorithm pulls you in.
Instead, find local meetup groups of businesses and start making connections. Be the local business doing this.
The OP specifically said tools "like this"
For anyone that isn't aware, the role of pca is to create new (synthetic) features that represent the original features.
It does not tell you which features of the original set are good for feature selection purposes.
ML also has a distinction between the system for training a model and the system that uses it, but that's just two projects to manage
Not saying there isn't shady stuff going on too. There definitely is, but even if there wasn't it is a skill based game.
https://donotplaythisgame.click/
In short, you accrue points while you aren't playing it, but you have to log into actually get the points (similar to "the game", which you just lost). You get your global ranking only after logging in though.
It's easier to criticize the actions of others than to take responsibility.
They are useful, but I think sometimes the advanced features run into the basic interfaces a bit, making it weirdly tricky to teach beginners without being confused.
So start with querying your big data to say what the top three event types are. Then slowly crank up the analysis complexity, but not too much. The data engineering has lots of scope for real solid and obvious applications.
1) Use unit tests to move quickly through to implementing The Feature 2) When The Feature is complete, run in a local environment to confirm it works 3) When that works, move The Feature to a development environment that more closely mimics Prod 4) Deploy to Prod
Each one of those steps takes an order of magnitude longer than the previous one, so should be done an order of magnitude less often. However if you are finding inconsistencies between steps, then alter local/dev to ensure more consistent testing. (i.e. if it works on Dev, it should just work on Prod, however there are always little issues).
A good recruiter is gold but it's a profession that has a large number of spammy practices.