lnguyen

If you're using Safari, you can read the article in reader mode even with the paywall message

One of the issues that isn’t obvious is the difficulty in actually doing any reported MMJ study, let alone one that was done by respected institutions. While one can argue about the significance of the small sample size, it’s amazing that there’s an actual reportable group

The issue is the THC vs CBD content that’s being provided. Most of the medical/medicinal aspects are focused on strains with more CBD while recreational emphasizes THC

You can turn on Airplane Mode then turn back on the services you want (except cellular data)

My "favorite" Clearcase server issue was one that took 2 weeks of uptime before it resulted in a crash on a up-to-date AIX installation. I had to wait until we had somewhat identified the timeline before engaging our ops team so they could log the crash and submit it back to IBM so they could investigate/fix

I have that set. It's not really a quality image, more VHS than DVD

It's been reported that he died shortly after arriving at the hospital

http://www.startribune.com/aftermath-of-officer-involved-sho...

Given the plundering of insecure Bitcoin exchanges, I'm reminded of this passage from Gibson's Count Zero:

The Wig punched himself through a couple of African backwaters and felt like a shark cruising a swimming pool thick with caviar

https://books.google.com/books?id=7RpZX8mYKVMC&pg=PT139&lpg=...

Don't make the job just about the code in front of you.

Use the opportunity you have right now to learn about working in a team (and possibly taking the lead/managing), managing customer requests and expectations, implementing business processes, etc.

All of this will be valuable whether you keep working at this company, another one or decide to work on your own ideas/dreams.

Why would you expect anyone in that position to expose themselves publicly? Although they could give useful feedback, it wouldn't be in their interest to deal with these issues outside of a formal process. Unless of course it's in their job title to handle developer relations. Even then it'd be more setting up coordination and less anything technical.

Granted without knowing what exactly that process could be accessed or what it is, I agree that you need to do something to "start the conversation." However, attacking is unlikely to achieve the results you want. This is especially true considering the imbalance in your relationship with Apple. I've worked a number of years in enterprise software and for large enterprises. You have to learn how to bring attention to issues and escalate them constructively and professionally. You also learn that you don't always get what you want.

Do the blog posts but be aware of the tone. Use the mailing lists. Get others to raise their voice and show that it isn't an isolated incident.

In the meantime, since the issue is out there and details are known, workarounds need to be figured out that can be implemented. Short-term, there should be things that can be done by app developers. Longer-term, a solution probably needs to be put in place in the project that will address the needs of both app developers and Apple. (Apple dropping use of the project may be a possibility but I don't see that as a win for anyone.)

Also realize that an app developer "losing an entire afternoon" is minor in the grand scheme of things. However inconvenient it may be to be that developer, unless it's an absolute show-stopper, any reaction or solution will take time if one is implemented at all.

How soon everyone forgets... The TRS-80 Model 100

http://en.m.wikipedia.org/wiki/TRS-80_Model_100

Legacy services.

If you're starting from scratch, you can choose a cleaner setup. But if you're dealing with an existing site, you have to figure out if and how you can migrate all the existing functionality. For any non-trivial case (or one with a realistic budget), you're not going to be able to just do a re-implementation and single cutover.

Being a non-profit sets an expectation of the actions the organization will take.

Also remember that until recently, Visa and Mastercard were also non-profit entities.

The reason those companies are still running the old versions is because even if they're out of support, they're known quantities. Implementing new versions will require development and testing to put in to place along with the possibility of additional upgrades (OS, other apps/libraries, etc.). Unless you have resources to handle that aspect in addition to any of your actual business, you're going to want to stay on a version for as long as possible instead of being on the upgrade treadmill that Microsoft/IBM/Oracle try to place you on.

Overkill for now. But it's best to learn the tools you will need while things are still simple. You know how things should get set up and can ensure that what you're telling Puppet/Chef to do achieves that.

If you wait until you've got a more complex configuration, you're fighting both the tool syntax and system setup requirements. Not to mention the clock that's ticking and telling you that you needed to be all up and running yesterday.

Actually it does. You turn off checking via -k

In general, it doesn't. It just looks like they've established a process where CI takes place on the shared master.

Builds/testing can happen on any branch, any repo. I'd like to have some local testing take place (for syntax at a minimum) before anyone submits changes to a shared branch.

This is why, at a minimum, you rebase (yes, rebase) your development branch before merging your changes onto the common branch on the shared repo. You catch conflicts in your work area without having to grind everyone's work to a halt while a fix takes place. Ideally you should rebase after every successful merge of changes to the common branch but that might not be practical depending on the change you're working on.

Branching often means not having to worry about the impact of making an experimental change: it may not go anywhere but you want to be able to try something out. You don't have any heavy lifting to start or to clean up.

And establishing good branching strategies are essential for any project that has any kind of parallel development. It doesn't matter if it's one developer or 200.

You may have an existing license-acceptance cookie depending on what else you might have done. Clear any oracle cookies and try again. You'll run into a fail page.

(I've worked on scripting JDK installs so have had to go around this by coding the cookie into curl and wget calls)

Oracle downloads rely on a cookie being set after agreeing to the license.

You'll need to start off here:

JRE: http://www.oracle.com/technetwork/java/javase/downloads/jre7...

JDK: http://www.oracle.com/technetwork/java/javase/downloads/jdk7...

It's a big detector with a lot of parts.

Standard procedure is to list all the researchers involved in the project. Not everyone will be directly involved in the specific analysis to find the Higgs.

There's also the bit about hiring of EA executives (John Schappert, Jeff Karp, Barry Cottle) who had access to The Sims Social and social IP (pages 13-14).

The best and brightest will work where they see opportunity and sufficient reward for the risk.

I'll readily admit that the core of ClearCase leaves much to be desired from a technology, administration and user perspective. Especially in comparison to git. But that's the difference a few decades of progress can make.

But what's built on top of it are definite wins in comparison to git and Github: UCM and lifecycle integration with ClearQuest.

Most developers don't know how/when to branch. UCM at least sets up a structure and process for that. There's also enough out-of-the-box security to control access to everything that most enterprises would care about. This is supported, documented, etc.

Managing an application's lifecycle is probably far more important in a large organization than most people experience in a small project or startup. Integration with ClearQuest allows everything to be tracked.

Since all of this are essentially "add-ons" to a core versioning tool, there's nothing to say something similar can't be done with git/by Github. It's just that they're not available _now_.

I'm guessing they're working with file formats that can't be diffed or merged. In which case all the version control is doing is just storing the file. Branching, forking or collaboration isn't possible in the way it is with text code.

In that case it really doesn't benefit them at all and is a chore. You'll only get them to use version control if it's hard mandate (good luck) or figure out a way to make it completely transparent to them (something like Time Machine).

The product market for enterprise VCS/SCM is also quite a bit different. It's no longer enough to make it easy for developers; you need to be able to provide better access controls/security and start managing the code lifecycle.

Github has quite a bit of work ahead of them to be on par with say IBM/Rational ClearCase/ClearQuest or CA Software Change Manager (aka Harvest). Definitely wish them luck.

But it's only one change.+

+ Technically true. The scope will be equivalent to 50+ change tickets. And he'll be able to blame someone else for any issues that result.

I'm going just a bit pedantic on this part: "when it's ready to merge, is rebased onto the latest canonical repo/branch before being merged in" should read "when it's ready to merge, we rebase the local development branch to the latest canonical repo/branch, resolve the rebase merge issues, and then merge the changes into the canonical repo/branch"

It's probably what you're doing but just saying it more precisely in the use of git (and SCM) terminology.

There shouldn't be any issue about where rebase is usable versus merge. It's more process than technical except if you're expecting git to handle things right out of the box.

None of these arguments are anything new: Any one who's worked with ClearCase should recognize them [1]. Read up on the UCM lifecycle.

[1] Software Configuration Management Strategies and Rational ClearCase (1st edition: http://www.amazon.com/Software-Configuration-Management-Stra...). And yes, it's from over 10 years ago...

If you're working in a group and structure your branches around releases (or really any logical way), you need to use rebase.

It can be a pain in the ass but it's the only way to guarantee that you're all consistently working from the same set of files/commits and that the your updates don't mix in other changes (aka chances for errors/regression).

See http://gitguru.com/2009/02/03/rebase-v-merge-in-git/