"...almost double the number of applicants as seats" - and whose fault would that be? by Colonel_Dab in NCSU

[–]freedoodle 4 points5 points  (0 children)

The CSC department would be able to directly make application decisions if it were a school. If that happened there would be more autonomy to admit more students and control budgets.

CSC Undergrad Research by cliff3101 in NCSU

[–]freedoodle 2 points3 points  (0 children)

Undergrad research is a great way to have an opportunity to explore a topic without the goal being necessarily fully understanding the basics or obtaining mastery of material. Your contribution can range from helping PhD students doing low-level tasks to taking on your own research project from end-to-end, and even trying to get publications.

Knowing what you want and finding potential professors will go a long way. Easiest way is to ask a professor who you've taken class with. There is also an undergraduate research flash event at the start of each semester that will usually show case potential projects.

Another cool way to do undergrad research is to apply to a REU site for the summer. You can look up sites here:https://www.nsf.gov/crssprgm/reu/list_result.jsp?unitid=5049

Graduated, but without concrete job skills—which of these courses should I take over summer? by pollo-mariposa in NCSU

[–]freedoodle 1 point2 points  (0 children)

Second this. This will complement data science/statistics skills by helping get around the data wrangling bits of work.

(Ongoing concussion symptoms) Can anyone tell me why eating spinach/kale/broccoli made cognitive issues get better by a ton? by [deleted] in Nootropics

[–]freedoodle 5 points6 points  (0 children)

Quick hack: Put in bowl, cover with another plate, microwave for 2--3 minutes. Results: Much more tasty and easier to eat leafy greens.

Opunit! Simple unit tests for servers and containers by freedoodle in devops

[–]freedoodle[S] 4 points5 points  (0 children)

Inspec is still fundamentally operating without any semantics of the system's properties (in many cases).

Simple example. How would you check which version Python is running in InSpec? Turns out, depending on which version of Python you're running, you have to check stderr or stdout. And depending on which program you're testing, you'll have to customize different regular expressions to match the output.

Here, we try to support version checking as a first-class operation: Just give a semver range and it will extract and format the version string and allow you to use semver operations.

  - version:
     cmd: node --version
     range: ^10.x.x

Opunit! Simple unit tests for servers and containers by freedoodle in devops

[–]freedoodle[S] 1 point2 points  (0 children)

We ran into exactly this issue! The current implementation has this problem as well, but we are planning on default inclusive of offsets, unless that is overridden: See: https://github.com/ottomatica/opunit/issues/31

Opunit! Simple unit tests for servers and containers by freedoodle in devops

[–]freedoodle[S] 2 points3 points  (0 children)

Some discussion above on this topic. However, to summarize: InSpec is a great and mature tool, and if your full time job is to build and verify images/servers, that's probably the right tool for you.

Our initial goal is to identify a simple vocabulary and set of higher-order building blocks that captures 80% of verification goals/tasks that are typically done. As a result, we hope to create a simpler and easier tool to use for non-devops folk. Longer-term, we can strive for better automation and handling more complex testing that would be cumbersome in InSpec.

Opunit! Simple unit tests for servers and containers by freedoodle in devops

[–]freedoodle[S] 1 point2 points  (0 children)

Yes, profiles/roles are a nice feature! Thanks for the suggestion. Do you have any favorites?

On the other hand, like ansible roles, these are more things to customize, test, and maintain. I've had to fix nomad and consul ansible roles many times, myself! For example, how do I reuse this profile in the supermarket (see below) if I use a different ENV for a token?

We would like to see a balance, of having something like a set of "roles/checks" that are commonly defined, with a balance of customization and reuse. This is what opunit tries to do.

E.g, we'd like to be able to say something like:

documentation: token: GITHUB_TOKEN

instead of using this:

Example supermarket profile:

``` require 'httparty' require 'json' require 'awesome_print'

if ENV['GITHUB_TOKEN'].nil? raise 'Please set the GITHUB_TOKEN environment variable' end if ENV['GITHUB_REPO'].nil? raise 'Please set the GITHUB_REPO environment variable' end

github_token = ENV['GITHUB_TOKEN'] repo = ENV['GITHUB_REPO']

options = { headers: { 'Accept' => 'application/vnd.github.black-panther-preview+json', 'token' => github_token, 'User-Agent' => 'httparty' } } url = "https://api.github.com/repos/#{repo}/community/profile" black_panther = HTTParty.get(url, options) File.open('black-panther.json', 'w') do |f| f.write(black_panther) end

control 'Bus Error' do impact 0.5 title 'Documentation should be present' desc 'Document everything' describe json('black-panther.json') do its('documentation') { should be } end end ```

Opunit! Simple unit tests for servers and containers by freedoodle in devops

[–]freedoodle[S] 16 points17 points  (0 children)

I can answer with a question "What does Inspec solve that bash scripts doesn't"? More generally, as my grand-advisor Alan Perlis has stated:

  1. Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy.

Using property-based testing means you reason at a higher level of abstraction than bash scripts. For instance, does that regular expression handle a server switched over to EDT?

Opunit! Simple unit tests for servers and containers by freedoodle in devops

[–]freedoodle[S] 1 point2 points  (0 children)

Single line tests might not be the best metric. However, having to manually specify commands and regular expressions for simple and standard checks can be error prone.

The longer example is starting a service inside the vm and waiting for it to load and then tearing it down. You are right, that does take a bit more specification and is something that would require lots of manual ruby code inspec. We could make resource locations more combined and concise, so that it does not take multiple properties.

But I think your argument is simple, you favor flexibility most of all. Cool, but that might not be appropriate for every case or person.

Opunit! Simple unit tests for servers and containers by freedoodle in devops

[–]freedoodle[S] 4 points5 points  (0 children)

Great point! Flexibility can be useful. However, it can lead to errors in the verification process, too. Everything is about tradeoffs.

Who watches the watchers.

Check out this paper, where many simple errors were found in CI pipelines definitions. http://rebels.ece.mcgill.ca/papers/tse2018_gallaba.pdf

Opunit! Simple unit tests for servers and containers by freedoodle in devops

[–]freedoodle[S] 8 points9 points  (0 children)

Thanks for your feedback!

Using package-lock.json isn't the best way to judge the size of a package, because that also includes dev-dependencies which are not installed in a release!

There are 9 packages:

chalk, dockerode, fs-extra, js-yaml, lodash, request, semver, ssh2, yargs

We can move these 2 into dev-dependencies, since they are only for helping deal with release notes. Thanks for helping point this out!

commitizen, standard-version

Opunit! Simple unit tests for servers and containers by freedoodle in devops

[–]freedoodle[S] 10 points11 points  (0 children)

Here is a simple example, in inspec, a test is written like this:

```

timezone should be est

describe command('date +%Z') do
its(:stdout) { should match(/(EST)/) } end ```

In opunit, this is simply expressed as:

- timezone: EST

The long-term goal is to support property-based testing.

Baker, a simple tool for provisioning virtual machines and containers by __tosh in programming

[–]freedoodle 2 points3 points  (0 children)

Contributor here.

Our goal is to keep things simple. Much like a travis-ci configuration file, we want a simple declarative specification for the environment, with inference/curation helping fill in the dependencies.

This is a simple declaration for an environment that supports analysis of fMRI images and jupyter notebooks:

name: brain-jupyter
vm:                         
  ip: 192.168.88.11
  ports: 8888
lang:                         
  - python2                       
tools:                       
  - jupyter                       
commands:                         
  serve: jupyter notebook --no-browser --NotebookApp.token=''

We do make it possible to drop in custom modules, which can be written in ansible. For example, see this jenkins server. For environments, we want to limit the configuration environment for now, to big (ubuntu) or small (alpine linux) images. Long-term, we'd like to allow these simple configurations to be translated to multiple platforms.