init

300-resources/Development/Better developers Using from X import Y in Python.md

@@ -0,0 +1,37 @@
+Title: "\[Better Developers\] Using 'From X Import Y' in Python"
+Author: [[Reuven Lerner]]
+From: 
+
+## Highlights:
+
+Is a variation on "import" that is commonly used, which looks like this:
+    from X import Y
+
+The idea is pretty simple: When you say
+    import foobar
+
+you're creating a variable "foobar" in the current namespace. That variable is a module, whose attributes are the global variables created in the module's file
+
+Whether you find it aesthetically ugly, or annoying to type, or confusing, or if you just want to put it in the current namespace, you can do that with:
+    from foobar import hello
+
+Or if you want both of them, you can say
+    from foobar import hello, x
+
+Once you have done this, the names "hello" and "x" are defined in your current namespace, and you can use them to access the module's attributes
+
+Note that I keep saying, "the current namespace." That's because "import", like "def", is a way to define a variable. When you use "def", you're both creating a function object and setting a variable (the function name) to point to that function object. And when you use "import", you're both creating a module object, and setting a variable (the module name) to point to that module object.
+
+But all variables can be global or local -- and modules are no different.
+
+I should note that while you can use an "import" statement anywhere, it's pretty rare in my experience to have it anywhere but at the global scope
+
+So: "from-import" loads the entire module, and puts the module in sys.modules. It then creates aliases to the specified names in the local namespace.
+
+And if you're using "from-import" because you want to save memory, or don't want to load an entire module, that's obviously bad news.
+
+When you say "from import *", you're saying that it would be totally OK for the module's variables to overwrite the variables that you have defined in the current namespace
+
+For starters, "from-import" ignores names that start with an underscore (_) character
+
+If I want, I can also define the variable __all__, a list of strings indicating which names should be exported when you use a wildcard

300-resources/Development/Development.md

@@ -0,0 +1,5 @@
+### Notes
+```dataview
+table file.ctime as Date from "3. Resouces/Development"
+sort file.name
+```

300-resources/Development/Mock Patching.md

@@ -0,0 +1,4 @@
+## Highlights: 
+`Mock.patch `  will intercept import statements identified by a string, and return a Mock instance you can preconfigure using the techniques we discussed above.
+
+we need to supply  `Mock.patch ` with a string representing our specific import. We do not want to supply simply  `os.getcwd `  since that would patch it for all modules, instead we want to supply the module under test’s import of os , i.e. work.os . When the module is imported patch will work its magic and return a Mock instead.

300-resources/Development/Monogo.md

@@ -0,0 +1,3 @@
+
+
+db.createUser({ user: "unifi", pwd: "unifi", roles: [{ role: "readWrite", db: "unifi" }] })

300-resources/Development/better developers computers are cheap people are expensive.md

@@ -0,0 +1,34 @@
+Title: "[Better Developers] Computers Are Cheap. People Are Expensive."
+Author: 
+From: 
+
+## Highlights:
+
+My point is that it took a long time for people to realize that it was OK to work with a high-level language, and that doing so didn't make you a worse programmer. When you use a high-level language, your programs might run a bit more slowly, but that's often an acceptable compromise.
+
+---
+
+**==In today's world, computers are cheap, while people are expensive.==**
+
+---
+
+Let's assume that a Python program runs twice as slowly as the equivalent Java program, and thus requires two servers instead of one server. In today's world, that server difference will probably cost a few hundred dollars per month.  If the programmer writing the software is 5x as productive, then that server is more than paid for by the increase in efficiency.
+
+---
+
+This doesn't mean, of course, that you don't need to worry about slow code, or that there's no need for C++ programmers in the world any more. But the need for speed is increasingly balanced by something even more important: The need for maintainable software.
+
+---
+
+One of the reasons I love Python is that the code is clear and readable, allowing me to join a new project and dive in, because the code is written similarly to all of the other Python code I've read and written over the years.
+
+---
+
+Better to save your colleagues (and company) money by making things more efficient for people, rather than for computers.
+
+---
+
+Your 1st comment on this article **Note:** Really interesting insight with the switch to a high level language to save people time and make debugging easier instead of saving server resources. It might not always be the right equation like in our case where the biggest expense are the servers but in many cases it would be true that human price > server price
+
+---
+