Readit NewsJimmyL commented on An Oregon creamery making vodka from milk atlasobscura.com/articles... · Posted by u/toomanyrichies
This is also being done[1] in Canada, in a project that started as a way to use the byproducts of the normal milk-making process in a way that didn't cost farmers anything.
[1] https://www.cbc.ca/radio/asithappens/as-it-happens-friday-ed...
I've had better experiences with DataGrip, but if I wasn't at a place that would pay for proper tools, DBeaver is an OK substitute. Neither, though, have the big thing I want in an analytical SQL workspace:
Simple charts
A whole lot of my work ends up with a three- or four-column table with one column of buckets, and the other being counts of how many things ended up in that bucket. I'd love a view where I could render that into a line or bar chart as a sanity check, and have it update in real-time as I change my query. Instead, I end up having to constantly copy/paste into Excel and do it there.
Yes, I should be using a proper BI or visualization tool for real reports. But sometimes I just need a quick line chart to show that yes, that one count is going in the right direction.
JimmyL commented on Security Guidelines for Congressional Campaigns techsolidarity.org/resour... · Posted by u/stablemap
I found this to have a lot of holes at best. If this is for end-users working with a campaign some of this might be appropriate, but really the campaign should have people in charge of security and a lot of things should be funneled through them. If this is for end-users then the advice about antivirus, etc. should be removed because that should NOT be an end-user decision.
First thing: How is the campaign going to be operating and handling documents? Security for the scenarios is going to be different.
* If it's going to be in one or more offices with tightly restricted access from outside those offices that's probably the best for security but may be less convenient. Primary approach: restrict access to a limited pool of "trusted" devices and keep those secure.
* Entirely cloud-based (e.g. GMail, Google Docs, etc. or perhaps the business/enterprise Office365 and OneDrive). Primary approach: Tightly control document access at the storage side, probably primarily based on user accounts, while allowing many devices.
* Using online storage but traditional desktop programs, etc. is a second option, but may be harder to control. Primary approach: None, this is a hybrid and I think it has all the weaknesses of both other approaches.
Second, be aware of the kinds of threats you need to be ready for. Big areas of concern that jump out at me:
* Data theft/exfiltration of sensitive campaign documents.
* Data loss/destruction - via malicious trashing by an intruder or via failure of key systems.
* Loss of access at key times - are there times where temporary loss of access to systems has a major impact? (I'm used to thinking in terms of electronic medical records for doctors' offices, where at the least a down EMR puts a huge crimp in ability to see patients.)
* Possibly addressing of faked documents, but I'm not sure that's an internal security matter that can be addressed beyond being able to say with confidence "Our network has not been breached and we have access/audit logs to prove it."
Focusing on what I'd recommend as the best option from a security standpoint (documents, etc. are stored within the network, documents can be accessed only from within the network, network access is tightly controlled, document storage is appropriately partitioned with security groups to limit access) some thoughts. This is also the kind of network I'm most familiar with - I'd never consider having any medical client using any kind of cloud storage for practice documents that could contain PHI/PII (Protected Health Information/Personally Identifiable Information).
Re: Updates, absolutely, everything should be kept up-to-date. Ideally patch status, etc. should be monitored for all systems. This includes network equipment as well, most notably routers and any wireless equipment.
Re: Anti-virus, I disagree - Choose a good managed AV product, use it, have someone whose job includes getting alerts from it and reviewing logs it generates. I'm partial to Bitdefender, but Emsisoft may also be a good choice and also uses Bitdefender's virus definitions as one component. I'd avoid Kaspersky these days. I say this because I see the logs for managed Bitdefender blocking of known and suspected phishing and malware sites and I get alerts when malware is blocked. A good AV product should also help protect against both hacked websites visited by campaign staff and spearphishing.
Re: Email, why is this document talking about personal email? Do not use personal email for campaign work. Do not use personal email on campaign systems (assuming the "closed network" approach). If staff need to deal with personal email because their sister-in-law just sent them the newest Elf Bowling, they can do it on their phones and/or their own time.
Re: Email, if using an email system that supports 2-factor auth, use it.
Re: Email Attachments, assume malice. The advice to open documents on a phone instead is not unreasonable since the phone viewer is unlikely to have the same vulnerabilities as a desktop program. Viewing documents in a different program may also be a viable option, particularly if your internal use of that program isn't well known (e.g. Word-based attacks are unlikely to impact LibreOffice).
Re: Email, Inbound email should be going through all sorts of filtering which may not stop all attacks but should at least be able to cut down on possible noise. As an example with Office365 Exchange, there are a bunch of options (under "International Spam") to block messages based on the language encoding, the country/region it was sent from, etc.
Re: Passwords, 1Password is a good option. 1Password Teams is probably a better one.
Re: Phones, the advice to use iPhones is probably good, particularly because current-enough iPhones all get software updates where Android phones from different vendors are all over the map. Possible exception: If you're using the all-cloud approach on Google services, the Pixel phones should be a viable choice. If feasible, something that can be remotely wiped (at least email) by a mail administrator is probably not a bad idea.
Re: Laptops, yep, full disk encryption, etc. and never plug in USB devices, but on a management side assume that laptops are a weak point and take steps to ensure that the damage from a compromised laptop can be limited.
Re: Wireless access for Phones, Laptops, Tablets, etc.: Consider not using Wifi AT ALL. If Wifi is used, lock it down to recognized devices, which should not include ANY personally owned devices, particularly including phones, tablets, etc. Any device that end-users are allowed to install software on is a device that should not be connecting directly to your network. If you're unfortunate enough to have a campaign office in the basement of a steel building, set up a separate "Devices" network (still with authentication) that those devices can connect to.
Re: Messaging, yep, Signal. Regard just about anything else particularly including SMS as being plain-text that a skilled attacker could read. Also be wary of apps like Join, MightyText, etc. that allow handling of messages and device notifications from desktops.
Re: Browser, I'm not sure I agree with a Chrome-only approach (why no Firefox?), but I don't have a big problem with it. One advantage particularly for individual installations is that it will auto-update in the background, and with process-per-tab I believe new tabs will get created on updated versions (can anyone who's read this wall of text confirm?). I agree with the use of uBlock Origin and HTTPS Everywhere - compromised ad networks particularly with targeted ads could be a real risk.
Re: Mobile Browser, Even more than incognito mode, Firefox Focus may be a good choice as a default for browsing that doesn't require logins to sites.
Did I leave any gaping holes? This is kind of off the top of my head.
>> the campaign should have people in charge of security
OK, but most don't.
Money is a very limited resource in campaigns, and almost all campaign managers will choose to spend it on direct mail and ads over hiring someone for IT security. Their thinking will go "this organization is only around for a year or two, and if we don't win then it won't matter what our IT issues were", and their colleagues in the world of professional campaigning will agree with them. If we're lucky - and I hope we are - the DNC/RNC will have a hotline and national support team for IT security that campaigns can call, but it'll get swamped fast.
Local campaigns don't do enterprise IT. Local campaigns buy G Suite and some old laptops, and leave them sitting around campaign offices in which plenty of not-well-known people come and go. They'll likely be administered by either a contractor hired to set up the offices, or by a friend of one of the early paid employees who "knows computers". While simple changes that individual users can do aren't as through as what you get with a proper security administrator, they're much more likely to get done.
If you're a local[0] campaign and a nation-state actor wants to attack you, they'll probably be successful - but anything you can do to tilt the odds in your favor (like this guide) will help.
[0] Senate campaigns will generally have a small IT team who can do most of the enterprise-level management things mentioned. National campaigns will have a well-staffed IT team to do all this and more.
JimmyL commented on Trello, “Jira Sucks”, and Tool Dysfunction hackernoon.com/trello-jir... · Posted by u/tablet
I feel like a big part of people hating on JIRA is that it creates a formal process you have to follow - something enforced by code, and not just "always move your card to this Trello column first". It’s also so tempting for middle-managers to generate bogus reports, based on metrics that the people doing the work know don’t matter.
Even with that, though, I haven’t found anything else as good for linking and organizing bugs and tasks, encouraging collaboration between departments and roles, recording discussions and decisions in the place they’re made, interfacing with the other tools we use to run development, and providing a rich SQL-like way to query tickets.
When setting up our JIRA, we made a few decisions to try and make life easier on ICs and hide the bad parts of JIRA:
* Ignore the permissions system. By the end, all we had were site-admins (who can control billing and add-ins), regular admins (who can edit workflows) and “everyone else”. Setting permissions up properly is tricky, impacts a lot of things, and didn’t add any value to our workflows. We preferred to make use of the audit log when weird things happened, and for the most part, tell people to do the right thing.
* Insist that workflows come from the teams. Individual teams were given a standard workflow when they started, but were encouraged to make it their own. Central management had to cope with what the individual teams wanted their workflows to be, and weren’t permitted to make them add statuses or transitions to make reporting easier. The only exception to this was around having to use a common set of resolution options.
* Open up the admin role to anyone who wanted it. If an IC or Team Lead wanted to make small changes to their team’s JIRA, they could just come sit with someone who knew how and work it out. If they wanted to make more significant ones, they received the 10-minute lecture covering the top five things that seem safe but will in reality break everyone’s JIRA setup, and then were given admin access to go do what they wanted.
In the end, some teams used a sophisticated ten-step workflow with granular transitions, and some used it as Trello – but they were all unified in one place, linkable and searchable, and had common support for discussion, auditing, and file management.
JimmyL commented on Ask HN: Switching from developer to project manager. What to keep in mind? · Posted by u/alaaf
Remember that you're not a developer anymore, and that the way you contribute to the team isn't coding. You're moving from a role that focuses on concrete contributions, to a role that focuses on creating leverage so that others can contribute better.
Your job now is to manage the state of the projects you're working on, and enable the developers on your teams. If you're coding, you're almost certainly not doing that to the degree you could be. The new job will be difficult. Change is hard, new skills are hard, and there are days you'll want to just go code something because it's easier to do and more fun.
Don't do it.
Your priorities are enabling your team and making sure that everyone knows and is on board with the state of your projects. In your new job, the way you succeed isn't by putting out code - it's by your projects and teams succeeding.
Make sure you like the sound of these priorities; if you don't, you should probably reconsider the change of roles.
Lastly, make sure that you understand what you're accountable and responsible for. Project managers don't (by default) have people responsibility, but at your company they might. Same question about doing product ownership, agile coaching, tactical team leadership, reporting, etc.
What are people's thoughts on Cloudformation vs Terraform for a project that only ever expects to use AWS?
If you end up using CloudFormation, don't write the JSON directly. Your programming language of choice should have a wrapper that maps objects to CloudFormation JSON - do your thinking there, use all the features your language offers, and consider the JSON you dump out at the end as an artifact you deploy (which happens to be readable). For Python, this is https://github.com/cloudtools/troposphere - I can't vouch for how accurate other languages' versions are, but I've never had a case where Troposphere didn't generate the right JSON for what I asked it to do.
CloudFormation is also nice in that it has access to a few API features which Terraform doesn't - specifically wait-conditions, automatically rolling-back updates when there's a problem, and a lot of the magic around UpdatePolicy/rolling deploys (although that doesn't work the way one would expect - a story for another day).
Having said that, Troposphere is pleasantly readable and has nice docs. The cross-platform integrations (for example, CloudFlare) add to the "just works" feeling. Some things are a pain to do in Terraform due to its strictness around being declarative and not having conditionals (e.g. having production and development environments that are similar, but not exactly the same), but there are some well-known hacks around them.
It also takes a very strong position around failed updates: it'll stop mid-change, tell you something's broken, and have you fix it. In the same situation, CloudFormation would roll back the changes to the state you were in before you started. Which one of those two failure modes you prefer is up to you. There are also some issues around having passwords and the like in your statefiles when you use RDS. You can avoid this if you go whole-hog into the HashiCorp stack (TF + Vault + Consul + etc.), but it's bugged me.
Lastly, If you're going to build something big and complex in TF, I suggest you do some reading of Charity Majors' rants on TF (https://charity.wtf/tag/terraform/). She has probably already run into the problem you're going to have.
So which would I use? Depends. If I want to create the same environment in a bunch of places (which also includes blue/green deploys), TF. If I want to do more complex things than that, CloudFormation.
That was a pretty big issue for us as well. We've gone through some acquisitions and we left with a bundle of different accounts.
Wound up taking a day and writing a ruby script that checked out an STS token, and exec'ed a new bash shell with the correct environment variables. the $PS1 has the account name in there so it's not too hard to know what shell points where. Also helpful that we set up a "control account" that handles consolidated billing and user login.
We've had some pretty good success so far, however I can definitely see how that feature would be good baked-in somehow.
We use https://github.com/atward/aws-profile/blob/master/aws-profil... to do pretty much the same thing, although without the $PS1 hacking. Our rule is that a user's default profile should always be the "control account" (on which they have permission to do nothing except STS and AssumeRole), and that they need to use this wrapper and explicitly specify a profile for all "real" API commands. This also works nicely with MFA.
Having this built into TF would be nice, but there are enough tools out there that don't support AWS role-jumping that I suspect we'll end up using that wrapper for a long time.
2-3 months of light work (it was the summer), in Toronto circa 2011.
I had zero professional experience, and bad grades. I knew that for my first job coming out of school, a lot of places would ask for a transcript...so I pointed most of my energy at places where the HR process seemed lax enough that I'd get to talk to developers (who could advocate for me) before I had a conversation where grades would come up.
At the start of my search, the Star/Globe had an insert with "Canada's Top 100 Start-Ups" - I cold-emailed all the ones in there which seemed interesting. A few got back to me, and one of the ones that did is where I'm still working.
As someone on the other side of the table now (at a ~25-dev shop), some things I think about when I'm considering new grads:
* I'm looking at passion, which I use as a proxy for long-term potential upside. You likely won't be a valuable contributor for 6+ months while I get you up to speed on my domain and what real-life professional programming is like. Some new grads can have an immediate impact, but most of those will have already been hired by Google/FB/etc. before they even think of my company. Convince me that you're the one I should be placing my bet on.
* If your CV talks about a mobile app you built, have it installed on your phone so I can play with it. If you talk about a web app, have it bookmarked and walk me though it. If you have one of those you're not excited to show me, I'm going to assume it's bad or you didn't finsih it (so don't mention it). If you don't have one of those and you're a new grad, I'm going to wonder why not. These don't have to be sophisticated; what you're showing me is that you're excited about technology, and can apply it in a non-academic, non-forced context.
* Show that you can communicate well. We're going to be spending a lot of time teaching you stuff, so I'm going to be probing to make sure that you can absorb it all (emotionally and socially).
* Don't focus that much on your specific tech stacks, aside from enumerating them. I'll assume your experience is of limited/academic depth only, and that you don't have much real-world experience. Don't boast that you know Scala when you used it for a project and a co-op term; focus on selling that if I need you to learn OCaml, you'll be a quick study.
Lastly, re: meeting engineers at meetups etc. - don't forget about follow-ups. Maybe the person you had a positive conversation with was just being polite...but it's more likely that they just forgot about the conversation. Send them an email a few days after to remind them you exist.
I still remember how one day there was a message on the announcements newsgroup about how the size of a key was increasing, only three or four days before the we'd start seeing the change in API responses. Dealing with this needed a database migration that I would need more time to schedule, and I sent back a polite-but-direct response to the generic posting email expressing my disappointment with how little notice we received.
A couple minutes later a Google Chat bubble pops up from some guy named gdb (aka Greg Brockman), who I subsequently learned was Stripe's CTO. He apologized, asked why the timeline was tough for me, and when I explained it, immediately set something on my account so that the migration would be delayed by a couple weeks.
8 years later I remain impressed by that level of customer connection from a senior executive, and the technical excellence that allowed them to special-case delay my migration.