josephmosby

Doesn't appear to be. Apple lists the MBP and iMac chips as one and the same - assume that the MBA would be added to this list. https://support.apple.com/en-us/HT208862

Another factor that is going to pinch IBM here: they're getting hit from the other side with professional services firms (McKinsey, Big Four, Booz Allen, etc.) now jumping into cloud implementation work. Also smaller but legitimate technical firms like Pivotal who capitalized on IBM dragging their feet in this marketplace.

So, if IBM's strength was "we can do services from anywhere," that gets busted by the rest of these players who can now compete at the same logistical level. And if they aren't hiring the best engineers, they're going to get slammed by Microsoft who will pay top dollar for them.

It teaches the same first principles in a smaller format with less room for error, but this particular board won't be able to scale up to a prod environment.

Agree with another commenter that an AWS EC2 F1 instance might be closer to prod for your purposes.

Programming FPGAs by Simon Monk and the Mojo v3 have been what I've been getting started with. It might be a little basic if you've been working in-depth with GPUs already, but the Mojo v3 is a great board to learn on - connects directly to your laptop via USB. It takes a lot of the magic out and makes it more like you're just programming an Arduino.

Think less about pushing your product, and more about aligning your product to a stated need.

Instead of "how do I get Product X into Company Y," ask "how can I help Company Y accomplish their mission with my product in a way they are currently unable to do?" The flipside of this question is "if I were CEO of Company Y, why should I want to buy Product X?"

Instead of "how do I convince Buyer Z to go with Product X," ask yourself "what are Buyer Z's incentives? Do they need to lower costs/increase their revenue/help their team communicate/etc?" Buyer Z has incentives - some of them corporate-wide, some of them specific to her/his day job, some of them very personal. Try to learn what those are.

Also remember that sometimes it's not a good fit, and that's okay. Preserve relationships. Sometimes you catch Buyer Z working for Company Y, and she says "right now, we're really not focused on $THINGYOUDO, and your price would be prohibitive anyway." Fast forward three months and she might have changed jobs into something that is very much $THINGYOUDO, and she now has a vastly increased budget. Much better for both of you if you have preserved the relationship.

Sales becomes a much easier road to walk if you remember "this person is a person just like me, and they've got things they're trying to accomplish in their day job. Let's see if I can help them out."

This is a phenomenal field choice for an online degree. I'm a little surprised that they didn't have a professional institution co-sponsoring it (like AT&T did for another GT program). One of the big players like Splunk or Symantec seems like an ideal fit for this.

Two researchers at DEF CON this past weekend showed that the situation is better but people are still using old tech for their crypto. So, better mathematically, but not practically.

Slides are here off the DEF CON media server: https://media.defcon.org/DEF%20CON%2026/DEF%20CON%2026%20pre...

I didn't find mine until recently, but even then - it definitely found me.

I worked really hard on stuff that I just "liked" enough that I said "hey, if this is all I did, I would be happy and would make enough money to live." This was actually something that Phil Knight talked about in Shoe Dog - he was an accountant, and he knew that if Nike totally failed, he could still be an accountant and eat.

Eventually I fell in with a group of people where a bunch of things lined up - it matched my technical skills, I liked the people I was working with, there were a set of long-term goals I really believed in, and there was career runway within those goals. I hadn't done anything proactive to find myself in that situation, I just tried to work hard and be pretty good at anything I was doing.

If you don't have a passion yet, I'd instead recommend getting a reputation for being responsible, proactive, and enjoyable to work with. Be an executor. That gets you introduced to people who have passions and need someone who can help them get the job done. Being around those people is critical to helping you discover your own passions.

In many cases those governments are the end users. They're buying the same licenses as run-of-the-mill businesses.

Furthermore, if you said "well, private users only can review the code," then every government is just going to ask its code reviewers to independently purchase private licenses. There's no way to keep government users out of source code reviews unless you totally block code reviews whole cloth.

There's also the often unmeasured benefits of the surreptitious Googling that many people do before meeting you. Bosses and clients alike will "look you up" after receiving your resume or a cold email, and that blog can make a positive first impression on someone who may never actually mention that they cyber-stalked you.

That depends on a few factors.

1. Can you cite tangible accomplishments where your work has disproportionately benefited the business? Did something really cool technically != did something that made the company more money or cut costs. If not, avoid asking until you figure out how to meet this requirement.

2. Are you working for an established organization where raises are done on a schedule (and have been on a schedule for years)? If so, you may be better off having the conversations to condition your boss towards a bigger raise in April rather than demanding one now.

3. Do you have data? Don't think you're less than the market value, come with data. StackOverflow has done developer compensation surveys in the past, and there's always Glassdoor, etc.

Unless you have demonstrably had a positive impact on the business that went over and beyond expectations for an engineer, you may wish to wait until April and see how raises shake out then. If, however, you can come with data and make a case that you're going beyond the call of duty in your role (something that you could also show to a new prospective employer in an interview), give it a shot.

You may want to reach out to the Medill Justice Project at Northwestern University (http://www.medilljusticeproject.org/). What you and your dad did is what they do all the time, so they may have some resources that can help out.

PCI-compliant networks often contain checks for credit card numbers being sent in plaintext over the network. Problem with that is that credit card numbers are computed according to a formula, and it's really easy to generate a bunch of fake 16-digit numbers that will pass the check. So if you want to troll your security team, generate a CSV with a stack of credit card numbers and drop it in a few places on a server. Even better, set up a script to send it over the network somewhere. Then wait for the scan.

Piece on check digits, for reference: http://www.datagenetics.com/blog/july42013/index.html

"Nonviolent Communication" by Marshall Rosenberg was very helpful for me. A great resource about choice of words and the internal assumptions we make when we communicate in certain ways. http://www.amazon.com/Nonviolent-Communication-A-Language-Li...

"Air gapped" means that there is a physical separation between two networks (i.e., there's "air" between them). If two networks are physically connected, there is always a chance that someone could bypass any software security restrictions. If the two networks aren't physically connected, there's no way to gain access to one network from another.

In this instance, the inflight entertainment network and the avionics network were physically connected, and the security researcher was able to gain access to the avionics network by connecting to the inflight entertainment network.

This reminds me of the Dutch Elfstedentocht, where they have a huge super-marathon skate across 11 cities: http://en.wikipedia.org/wiki/Elfstedentocht

Would be awesome to see a similar race develop in Canada.

True, but DC isn't a traditional metro area. The entire regulatory structure changes once you leave the borders of DC, because you've moved into a new state (Virginia or Maryland). Uber's coverage area for this service takes a hard stop at the DC borders to keep them from running into a new set of state laws and taxes they'd have to deal with.

DC is Uber's second largest market outside of San Francisco - and that includes Chicago, NYC, LA, etc. It's a test kitchen for a lot of consumer services because it's got a lot of different demographics under one roof. It's also relatively small, making it easy for Uber drivers to get around the area without incurring a bunch of extra costs for the company. Grocery delivery is also super popular in DC already.

San Francisco, by contrast, is almost too perfect. It would no doubt be successful there, but it doesn't give them as good of a feel for how this service would fare outside of Silicon Valley where these types of ad-hoc delivery services are far more common.

If a federal employee is asked to do any work whatsoever by a supervisor when on furlough (i.e., not getting paid), the U.S. government could be sued for a violation of the 13th amendment. Making it illegal for federal employees to do any work whatsoever means that the government can place the charge back on an individual if they choose to work.

A large part of the push for crowdfunding has come from entrepreneurs and their advocates who believe that a larger pool of funds will be beneficial to the entire country. However, investors expect that the regulators are watching out for them when they invest, by making sure that they are not being maliciously misled by stock salesmen.

The SEC is struggling to write rules that keep that investment expectation intact while still fulfilling the requirements of the JOBS Act. It is nowhere near an easy task. If this had been pitched with the nasty truth - that opening the crowdfunding door meant that a lot of investors would lose their entire investment when the company went bankrupt - then we might have had some faster turnaround. But instead, Congress requested that the SEC write rules that would offer investors the same level of assurance for startups that it requires for large publicly-traded firms. That doesn't get done in a Congressional pie-in-the-sky deadline.

As I stated in an earlier comment, I would likely have a different experience with Django now. Django was the first framework I attempted to learn, so I'll wholeheartedly admit that some of that was inexperience with web applications (started programming with non-web VB and Java).

I could write much of the same post and have it apply to Django as well. Django is designed to abstract away work, which means that it's difficult to really see what your application should be doing if you don't already know. If you've learned how to manage user authentication manually, you can appreciate and tweak what Django/Rails are doing. If your first experience with a web framework is having Django manage all of that for you, then you have no idea how to tweak it or debug it.

Ultimately, this is not a Django versus Rails debate - I just used my current Rails experience and prior Django experience as anecdote. I can't claim enough knowledge of Django or Rails to even advise someone on which to learn; all I can do is talk about my own experience and raise questions.

> It's pretty damn awesome to spend all day writing business code rather than support code.

One-thousand times this. I've had some headaches with gems (chronicled earlier), but if you're building an app with minimal add-on gems then development speed is incredibly fast compared to other frameworks.

> if you know what apps and middleware to disable.

And when I was learning Django, I didn't know this. I moved to webapp2 because I could put only what I wanted in an application. I'm sure that if I sat down and re-dedicated myself to learning Django like I'm doing with Rails, I might have a better time at it the second go-around.

Actually, I started with Django, then got pissed off because trying to twist Django around to do something non-traditional gets messy fast. webapp2 is spartan by comparison and makes you do more extra work, but at least you know what you're getting into because you have to write a lot of it yourself.

IMO, Django's great if you want to make something regularly published (i.e., blog, news site, etc.). But you have to get creative quickly if you want to do something else.

I eventually jumped to doing more webapp2, and I know there's a devout Flask community as a Django alternative. Haven't played with enough Flask to say anything yea or nay for beginners, though.

The scaffold boilerplate did a lot of extra work, but didn't seem to overstep its bounds with extra code too much. Does Rails encourage me to eventually complexify the application's routes and methods to a point that the scaffold won't make any sense at all?

Auto-generated code is great - I'm more questioning if it's causing learning gaps when people try to move to languages that don't have the community or commonality as Ruby/Rails.

Ruby seems to be an anomaly in that you can pretty much obscure away the hard parts of building a web application, but have it still be programming. If a programmer starts with Rails, does that impact their ability to eventually go on to other things?

I had not really thought about why Python development generally expected a virtualenv until now. If you haven't been in the Python world at all, virtualenv essentially sets up a miniature development environment within your working folder. System Python might be version 2.7.3, but inside my virtual environment I can run Python 3.0. It's a nice little hack around the problem of multiple Python versions... doesn't solve the root cause, but at least you can stitch it up with one step.

Actually, I've tried to stir the comment pot on Python posts and have not received near the same feedback. Now, that could easily just be indicative of the languages of choice among Hacker News commenters.

> My assumption is that devs in Python try to stick to the Pythonic way of doing things across modules, which helps maintain interoperability.

Yep. And that's also what I tried to do when I first started with Ruby, until another commenter explained to me that Ruby is different.

We were discussing the syntax of RSpec, and I was griping that RSpec was so linguistically different. Commenter explained that RSpec is very clear that it wants to have a different flow than pure Ruby because RSpec looks like a set of user stories. That means I'm going to have a hell of a time trying to stick RSpec into another use case, but I can't argue that the rationale for RSpec's DSL makes sense.