-
As someone who’s started learning Go in the past month, I can’t stress enough how much example usages help. Reading a function signature alone (as most of the golang docs are) is pretty difficult when you’re trying to wrap your head around a new concept. But when there’s a nice working example it makes things very tangible and easy to understand. From the repeated exposure thru example is also a great way to reenforce language idioms and best practices.
-
One of the things I’ve pledged to do in new code I work on is to provide the following:
- a high-level example in the package godoc
- an example in the tests (see the testing docs for more on this)
Of course, I also strive to write useful function documentation, as well. I don’t always do this, but I consider solid, usable documentation as part of the release process. Software isn’t useful if it isn’t usable.
-
I too learned Go in the last month. I found the playground to be pretty useful as an exploration tool while browsing codebases in my browser. It’s simple, but it significantly cuts down on the context switching costs between a text editor, a terminal to run code, and another pane that you are viewing code or the spec in.
-
-
epanastasi
4 years ago
|
link
| on:
Parents May Be Your Secret Weapon For Recruiting and Retaining Millennials
My initial reaction to this was.. “wow, that’s quite a story!” However, it did get me thinking quite a lot. And the anecdote at the beginning of the article aside; the overall point is a valid one. There are a lot of factors that go into a person’s decision making process when evaluating a company. It would be foolish to overlook the fact that, for some people, a parent’s opinion carries weight in that process. How much of a impact it has obviously varies among different age groups & cultural backgrounds.
In the past, I’ve had an interview candidate decline an offer because their parent thought it wouldn’t be wise to leave their current job so soon after starting it – even though that candidate was excited about the new job offer.
Consider the idea that building a company environment that appeals to one’s parent is probably not that different from an environment that appeals to a spouse, child, friends, etc. How often do people consider a job because it allows them to be closer to home? Because it offers child-care? Because it provides healthcare benefits to a partner? … How radical is it to consider that one’s parents are worth the attention too?
-
It’s not radical to consider parents as part of the recruiting pipeline, but the recommedations in the article go far past consideration. I can understand “Take Your Parents to Work Day”, but holding separate mentoring workshops crosses a line.
The reason that colleges bring parents into the recruitment process is to calm their fears, as this is the first time their children have left home. I think that treating jobs the same as acceptance into a four-year college is unfair to new hires.
-
-
It’s a fair point that the article’s specific recommendations may go pretty far, and I don’t mean to say we should treat employees like children who aren’t capable of making their own decisions. Or companies should cater to a parents wishes. But I still think that the higher-level message is not that far off the mark. I don’t necessarily see the value in solely parent-specific content/processes, but I think that paying attention to family, in general, is an important part of having a healthy work environment for both recruiting and retaining employees.
In general I do believe that how people live and work is changing; the decisions we make today as a workforce are different from those a generation ago. I would like to see more research and data before dismissing the value of parents in the process.
-
-
-
I’m really impressed with this, but then again I don’t do much reverse engineering.
Seems like the vulnerability in Snapchat could be mostly mitigated by preventing the MITM with the use of some kind of certificate pin within the Snapchat client.
I’m curious whether it’s common practice to pin the actual cert or to just pin the known CA cert to verify against? I think it’s enough to pin the CA cert for most applications, since you are already implicitly trusting your CA not to grant a cert representing your entity to another party. Using a self-signed certificate and pinning it would also be a solution I think.
But if you are a mobile developer using HTTPS for network communication I’d be interested in what you have implemented.
-
You’re correct about the two possible solutions. Moxie wrote a great article explaining how to do this for Android applications.
The choice of using a self-signed certificate or trusting a single CA certificate depends on the traffic profile of your application. If your application only talks to servers that you control, it’s in your best interest to take the time and generate self-signed certificates. If your application needs to talk to servers outside of your control (such as a browser or IM client), trusting a single CA certificate is the way to go.
-
-
I believe you could work around this by trusting a wide set of known, good CAs. Basically whitelist all the legit CAs - So if the owner changes from Verisign, to Digicert, for instance, you won’t have to change anything. But it does prevent someone malicious from trying to install an self-signed CA.
-
-
-
-
I always feel like I’m missing something when I read an article that involves installing a CA on the victim’s phone/computer. If you have that kind of access, aren’t there a myriad of other things you could do? Can someone help me understand why things like this are notable if they require installing a CA like this?
-
Installing the certificate on his phone was just a way to fool Snapchat into validating his proxy that he setup. The “victim” here isn’t the owner of the phone, it’s the application itself.
It’s interesting to note that a user can essentially bypass SSL out from under an app; this might not be that exciting to MITM yourself for most apps, but for Snapchat it allows the user direct access to the data they’re trying to restrict from the user.
-
As a recent convert to Go, here are my thoughts…
The type system is just different. It does feel unlike other languages I’ve used, and it can feel a bit unintuitive at times. For instance, parsing a lot of arbitrary JSON feels like falling into a quagmire of type assertions. My code quickly turns into a wall of text like this:
I know parsing JSON in any typed language can be a pain. I’m still not sure if there’s a better way to do that?
The other bits that feel confusing is when you can use type conversions vs type assertions. Also, at first glance anonymous fields create types that walk & talk like a Foo, but can’t be converted to a Foo. It took me longer than it should have to realize that the anonymous fields can still be referenced directly. In general, the type system works for me in all the code I write for myself; the only times I’ve had real trouble wrestling with types is when I’m trying to integrate with a library that wasn’t designed to be used the way I was trying to us it. More often than not I feel like I’m trying to fit a square peg into a round hole – as I’m starting to write more library code myself I’m trying to get a better handle on best practices for good go library design.
As far as Exported Identifiers, the only issues I’ve had were writing a large amount of code with a non-exported field name and then realizing later that I wanted it exported (or vice-versa). The change turns into an O(n) update for every usage of the field as opposed to an O(1) update at the declaration of the field. It just catches you at build time when you miss a reference somewhere, it’s not a big deal as long as you don’t have a long build time. Once again it kinda goes into building a good library from the start – the cost of making a poor API decision early on can translate to a lot of work later trying to fix it.
You shouldn’t be using JSON like that. You should be defining structures in your program that mirror the data you expect to receive, json.Unmarshaling into them, and accessing the struct fields directly.
As peterbourgon mentions below, you shouldn’t be unmarshalling everything into a map[string]interface{}, as you lose compile-time type safety.
If you’re unsure of the JSON that you’ll be receiving, at least use something like mapstructure which will return sensible errors when decoding fails.