angr

writings from zac anger, who is not all that angry

FP in JS

April 03, 2016 — Zac Anger

Notes taken while going through this guy's videos.

You should watch them all. He's great.

'use strict'

//
// HOF
//
// Higher Order Functions
// functions are values
// const something = function > function something
// obvs functions passed into functions
// composition yay
// example: filter (method on array, takes another function as action)
// filter's should return true or false to determine whether item belongs in arr
let something = [{foo : 'bar'}, {quux : 'baz'}, {whatever : 'target'}]
let newArr
for (let i = 0; i < something.length; i++) {
  if (something[i].what === 'target') {
    newArr.push(something[i])
  }
}
// vs
let newArr = something.filter(thing => {
  return thing.what === 'target'
})
// or, using reject
let isTarget = something => thing.what === 'target'
let notTarget = something.reject(isTarget)
// note: there's also find. that returns just the first item that matches.

//
// Map
//
// map's cb returns a transformed object to put into array
let peeps = [
  {name : 'geordyn', relationship : 'bffl'                   }
, {name : 'erin'   , relationship : 'number one bro'         }
, {name : 'ryan'   , relationship : 'nemesis. also, the one.'}
, {name : 'andrew' , relationship : 'special mormon'         }
, {name : 'sarah'  , relationship : 'grandma'                }
]
// non-functional way of doing getting an array of the names
let names = []
for (let i = 0; i < something.length; i++) {
  names.push(something[i].name)
}
// vs
let names = peeps.map(peep => peep.name)
let about = peeps.map(peep => peep.name + ' is my ' + peep.relationship + '.')

//
// Reduce
//
// map, filter, reject, and find are fairly specific list transformations.
// reduce is is more of a swiss-army knife. it can do just about anything.
// reduce wants an object, though. (yes, it's a method on the array prototype.)
let stuffToSum = [
  {amount : 4   }
, {amount : 16  }
, {amount : 1024}
, {amount : 4096}
]
// so...
let total = 0
for (let i = 0; i < stuffToSum.length; i++) {
  total += stuffToSum[i].amount
}
// vs
let total = stuffToSum.reduce((sum, stuff) => sum + stuff.amount, 0)
// this is adding stuffToSum[0].amount to sum (which is initialised at 0)
// and returning that sum, then going again with stuffToSum[1].amount and
// the current sum (4), and so on.
//
// let's say we have some file in TSV format, like below. (i'm using 4 spaces
// to represent a tab here, since tabs = 2 spaces in all my editors, and 2 spaces
// isn't large enough to clearly distinguish fields here, i think.)
// miss lady    an item    7    20
// miss lady    a thing or two    75    2
// some dude    another product    33    9
// some dude    some product    100    1
// we need to transform this into a nice looking object (containing two objects,
// one for each person, each containing an array of objects that are the items bought).
import fs from 'fs'
let contents = fs.readFileSync('./thatFile.tsv', 'utf8')
.trim()                        // remove trailing newline
.split('\n')                   // split into array of strings at newlines
.map(line => line.split('\t')) // \t is a tab character
.reduce((persons, line) => {
  persons[line[0]] = persons[line[0]] || []
  persons[line[0]].push({
    name  : line[1]
  , cost  : line[2]
  , quant : line[3]
  })
  return persons
}, {})
console.log('contents: ', JSON.stringify(contents, null, 2))

//
// Closures
//
function sendReq(){
  let reqId = 'asdf'
  $.ajax({
    url : '/someurl'
  , success(response){
      console.log('request ' + reqId + ' returned')
    }
  })
}
// see, we don't have to pass stuff around here. reqId is going to be 'asdf'
// no matter when jquery's ajax finishes whatever it's doing. nice.
// there's also this classic example:
function makeAdder(x){
  return(y => x + y)
}
let
  add4 = makeAdder(4)
, add8 = makeAdder(8)
console.log(add4(16))
console.log(add8(64))

//
// Currying
//
// so, you've got some arguments. you could have a function that
// takes your bunch of arguments and does stuff with them. or you could
// have a function that takes your first argument and winds up returning
// a function that takes your second argument which returns a function
// that takes your third argument... etc., you get the idea.
let self1 = (name, age, language, location) =>
  `Hi, I'm ${name}, age ${age}. I speak ${language} and live in ${location}.`
console.log(self1('zac', 26, 'english', 'utah, i guess'))
// vs
let self2 = name => age => language => location =>
  `Hi, I'm ${name}, age ${age}. I speak ${language} and live in ${location}.`
console.log(self2('zac')(26)('english')('utah, i guess'))
// why? maybe i don't know everything about myself yet, but my app will find
// out some of this information later. so i call self('zac'), have a birthday,
// call self(27)('english') because it's been another year and i still only
// speak one language, and then i call self('texas??') because i've moved.
// now, finally, i have the return value (the introductory sentence)!
// what about self1? we could always use something from some library to
// transform it, like wu.js's autoCurry, or whatever. for the sake of familiarity,
// try lodash (first npm i -S lodash):
import _ from 'lodash'
let me = _.curry(self1)
console.log(self1('zac'))
// yay! okay, another example.
let
  guitars = [
  {brand : 'ovation'    , type : 'acoustic' }
, {brand : 'silvertone' , type : 'acoustic' }
, {brand : 'esp'        , type : 'electric' }
, {brand : 'teton',     , type : 'acoustic' }
, {brand : 'danburn'    , type : 'electric' }
, {brand : 'homemade'   , type : 'cigar-box'}
]
, isType    = (type, obj) => obj.type === type
, electrics = guitars.filter(x => istype('electric'), x)
console.log(electrics)
// okay, so using the same guitars array:
import _ from 'lodash'
let isTypeCur = _.curry((type, obj) => obj.type === type)
  , acoustics = guitars.filter(isTypeCur('acoustic'))

//
// Recursion
//
// recursion is not at all a difficult idea. won't even
// bother laying it out here, really. a function calls itself
// until it's done calling itself. it's a super useful way to
// program, especially in actual functional languages.
// es6 makes recursion a lot nicer. we can get rid of the
// if statement in the below function in es6 because we won't
// end with a 'RangeError: Maximum call stack size exceeded
// or whatever.
let countDown = num => {
  if (num === 0) {
    return
  }
  console.log(num)
  countDown(num - 1)
}

//
// Promises
//
function loadStuff(url, cb){
  let img = new Image()
  img.onload = () => {
    cb(null, img)
  }
  img.onerror = () => {
    let msg = 'failed loading ' + url
    cb(new Error(msg))
  }
  img.src = url
}
export default loadStuff
// with
import loadStuff from './loadStuff'
let addThing = src => {
  let el = document.createElement('img')
  el.src = src
  document.body.appendChild(el)
}
loadStuff('/thing/to/load.png', (err, img) => {
  if (err) {
    throw err
  }
  addThing(img.src)
  loadStuff('/thing/two.png', (err, newImg) => {
    if (err) {
      throw err
    }
    addThing(img.src)
    // etc
  })
})
// vs
function loadThing(url){
  return new Promise((resolve, reject) => {
    let img = new image()
    img.onload = () => {
      resolve(image)
    }
    img.onerror = () => {
      let msg = 'failed loading ' + url
      reject(new Error(msg))
    }
    img.src = url
  })
}
export default loadThing
//with
import loadThing from './loadThing'
let addThing = src => {
  let el = document.createElement('img')
  el.src = src
  document.body.appendChild(el)
}
Promise.all([
  loadThing('/path/one.png')
, loadThing('/path/two.png')
// , etc
]).then(images => {
  images.forEach(img => addThing(img.src))
}).catch(err => {
  throw err
})

tags: functional-programming, javascript, js, fp, functional, notes, examples, map, filter, reduce, promises, closure, closures, recursion

so, tweet it?  

node-fs basics

February 12, 2016 — Zac Anger

this is another one that'll be presented just as a giant code block.

// using files in node
var fs = require('fs')
var buf = new Buffer(1024)

// reading asynchronously
fs.readFile('foo.md', function(err, data){
  if(err){
    return console.error(err)
  }
  console.log('async read: ' + data.toString())
})
// and synchronously
var data = fs.readFileSync('foo.md')
console.log('sync read: ' + data.toString())
console.log('#############\n')

// opening
// fs.open(path, flags[, mode], cb)
// flags can be r (r), r (rw), rs (r synchronously), rs+ (rw, sync),
// w (write), wx (fails if file exists), w+ (rw, creates file (or truncates existing)),
// wx+ (fails if path exists), a (append), ax (fails if path exists),
// a+ (file for read & append), ax+ (fails if path exists)
console.log('opening file')
fs.open('foo.md', 'r+', function(err, fd){
  if(err){
    return console.error(err)
  }
  console.log('opened')
})

// information about files
// fs.stat(path, callback)
// .isFile() returns true if file, .isDirectory returns true if dir,
// isBlockDevice returns true if block device, isCharacterDevice...,
// isSymbolicLink ..., isFifo, isSocket
console.log('getting file info')
fs.stat('foo.md', function(err, stats){
  if(err){
    return console.error(err)
  }
  console.log(stats)
  console.log('got yer file')
  console.log('symlink? ' +  stats.isSymbolicLink)
  console.log('char? ' + stats.isCharacterDevice)
})

// writing: fs.writeFile(filename, data[, options], cb)
console.log('gonna write a file')
fs.writeFile('bar.md', 'stuff!', function(err){
  if(err){return console.error(err)}
  console.log('written!')
  console.log('reading that now')
  fs.readFile('bar.md', function(err, data){
    if(err){return console.error(err)}
    console.log('async read: ' data.toString())
  })
})

// closing: fs.close(fd, callback)
console.log('opening file')
fs.open('bar.md', 'r+', function(err, fd){
  if(err){return console.error(err)}
  console.log('opened')
  console.log('reading it')
  fs.read(fd, buf, 0, buf.length, 0 function(err, bytes){
    if(err){console.log(err)}
    if(bytes > 0){console.log(buf.slice(0, bytes).toString())}
    fs.close(fd, function(err){
      if(err){console.log(err)
    }
    console.log('closed!')
    })
  })
})

// truncating: fs.ftruncate(fd, len, cb)
// ... meh

// deleting: fs.unlink(path, cb)
console.log('gonna DELETE a file!')
fs.unlink('bar.md', function(err){if(err){return console.error(err)}
console.log('deleted!')})

// mkdir: fs.mkdir(path[, mode], cb)
fs.mkdir('./test', function(err){
  if(err){return console.error(err)}
  console.log('created a directory at \'test\'')
})
fs.mkdir('./asdf', function(err){
  if(err){return console.error(err)}
  console.log('created one called \'asdf\', too!')
})
// fs.readdir(path, cb)
fs.readdir('./', function(err, files){
  if(err){return console.error(err)}
  files.forEach(function(file){
    console.log(file)
  })
})

// fs.rmdir(path, cb)
fs.rmdir('./asdf', function(err){
  if(err){return console.error(err)}
  fs.readdir('./', function(err, files){
    if(err){return console.error(err)}
    files.forEach(function(file){
      console.log(file)
    })
  })
})

// there are a whole bunch of other methods, but i feel like this is good enough for now, yes?

tags: node, fs, node-fs, javascript, basics

so, tweet it?  

Javascript Operators

February 06, 2016 — Zac Anger

(Just a little cheatsheet/list for my own easy reference--and anyone else's, too, of course. This is like maybe 83 percent just copied from MDN.)

JAVASCRIPT OPERATORS

There are a whole whole bunch! Here's most of 'em, kinda hopefully split up and sorted in some sort of order that makes sense. It's always worth just taking a peek at the spec or MDN or whatever, especially it looks like actual standards are going to be getting actual changes within actual human lifespans now.

read more...

tags: javascript, operators, cheatsheet, reference, ecmascript

so, tweet it?  

ES6 Notes

January 18, 2016 — Zac Anger

(These are some random notes from a lecture on ES6.)

let = var, but block scoped, finally. this means no leaks. Let can't be redeclared outside of its block, because it doesn't exist outside of there.

const = var, but it's a constant, finally. this means variables you can't fuck with, man! for simple things, that is. const x = 2; x = 3 does not work. however, parts of a const are mutable; that is, const y = [0, 1, 2, 3]; y[0] = 7 does work. Constants can be global or local, that's just up to how you declare it. Const and let behave the same no matter where you declare them; the difference is that const can't be defined again, whereas let can be redefined. Neither of them can be declared again.

read more...

tags: js, javascript, ecmascript, es6, es2015

so, tweet it?  

Electron and NW.js

January 15, 2016 — Zac Anger

Electron (formerly known as Atom Shell) and NW.js (formerly known as Node Webkit) are similar projects that bring Javascript to the desktop. They're both based on browser runtimes. Electron is sponsored by Github, and uses libchromiumcontent and Webkit 537 (as of Autumn 2015). NW.js is sponsored by Intel and uses Chromium and Blink/Webkit 537. They both use the V8 JS engine (from Chrome), are fully open source (MIT Licensed), can access a variety of open and licensed codecs, work on Unix-like systems (and, with a little extra work, on Windows), and can use Flash (in Electron's case, through the Pepper plugin). The biggest difference I've had in working with them is that Electron, being currently more popular (likely because of the Github support, and the popularity of the Atom editor, which is built on Electron) is usually closer to the current version of Chromium, and NW.js is usually a few versions behind. Electron seems to have a lot more community activity around it right now, too, so there are a lot of useful NPM packages like Electron-Prebuilt (and a lite version) and Electron-Packager (and an interactive version!). Electron also needs a Javascript entry point, which looks something like this:

var app           = require('app')  
  , BrowserWindow = require('browser-window')  
require('crash-reporter').start()  

var mainWindow = null  

app.on('window-all-closed', function(){  
  if(process.platform != 'darwin'){  
      app.quit()  
  }  
})  
app.on('ready', function(){  
  mainWindow = new BrowserWindow({  
    width                : 1200  
  , height               : 800  
  , 'accept-first-mouse' : true  
  , 'title-bar-style'    : 'hidden'  
  , 'node-integration'   : false  
  })  
  mainWindow.loadUrl('http://127.0.0.1:9090')  
  mainWindow.on('closed', function(){  
    mainWindow = null  
  })  
})  

That 'node-integration' line is really important if you want to use certain client-side libraries like Angular or jQuery that use the word 'module;' your stuff will just completely break without it.

NW.js, on the other hand, can just be pointed at your index.html, and that's enough to get started. That's really convenient, but for my own uses I've found that Electron has a lot more options. Its binaries are significantly larger, but there are evidently ways to cut them down. Don't count on being able to build an Electron app in less than a hundred megs, though.

If you're doing something small, like a text editor or some other little widgety kind of app, you'd probably still be better off with Qt or GTK--you can write a full text editor in GTK-Webkit with Python in less than 16kb, and that's if need a full rich-text interface with buttons and such. But for larger apps, and especially for apps you've already written for the browser, NW.js and Electron are both really great options. If you're going to be relying on a lot of the Node environment, Electron's got a better interface to Node because of its separated rendering and browser engines, but you do have to keep in mind that you'll be limited as to what client-side libraries you can use.

tags: nwjs, electron, desktop, js, javascript, apps, node

so, tweet it?  

Elm (notes)

January 14, 2016 — Zac Anger

Differences from JS:

  • Elm has multiline string support, with triple sets of quotes, eg """multiline string"""
  • Elm cannot use single quotes for strings. Elm uses single quotes to denote characters.
  • Booleans are uppercase.
  • Objects use = instead of :, so {key: value, key2: value2} in JS would be {key = value, key2 = value2} in Elm.
  • point.x = 42 in JS would be {point | x = 42} in Elm.
  • Functions are greatly simplified. function(foo, bar){return foo+bar} in js would be \foo bar -> foo + bar in Elm.
  • Math is a little simpler: Math.max(2,4) is just max 2 4. Same with min. Math.pow is just ^, eg Math.min(1, Math.pow(2, 4)) is min 1 (2^4).
  • numbers.map(Math.sqrt) would be List.map sqrt numbers. points.map(function(p){return p.x}) becomes List.map .x points.
  • 2 < 4 ? 'WHAT' : 'how?', if 2 < 4 then "WHAT" else "how?"
  • var foo = 72; let foo = 72 in...
  • No return statements; everything is an expression.
  • String.length "asdf" rather than 'asdf.length'

Mostly it looks pretty neat, but there's virtually nothing out there for actually learning it, so I'm already kind of over it....

Note that the 'EventLog.elm' in this directory doesn't actually need the start-app package anymore; turns out it's really easy to just wire the damn thing up all on your own.

read more...

tags: js, haskell, functional, programming, javascript, elm, lang, language

so, tweet it?  

Front-End Performance Notes

December 28, 2015 — Zac Anger

Performance matters. That's just a thing. I really don't care all that much about the browser-side stuff, personally, and I'm a wee bit sick of a lot of the client-side frameworks that have most of the market, because they mean you really have to care about using a lot of JS in the browser... because that's where you're doing most of the work. Things like Angular really show off this kind of horrible way of building apps. Putting all the work in every person's browser sure makes a lot of sense if you've got one tiny SPA and you're serving it from a home netbook or whatever... but come on, people. Stop hurting users. Be realistic. It's not even about doing what's probably actually the right thing to do... it can, if you want, just be about the dollar. Users don't want to wait. No one wants to wait. Sending out a whole bunch of scripts to a three-year-old knockoff tablet from China that's running on DSL out in the country and then figuring that user is okay with waiting while their device slowly loads it all in and slooowly runs the scripts and then finally starts showing them the goddamn site they're trying to see... that's how you lose people. There are truckloads of studies out there about the negative impact of every millisecond, so I won't keep rambling, and will start getting down to some note-taking and summarizing.... Oh, right. I'm reading through this little guide, right now, so that's what sparked this. I know I've read it before, but I'm really hardcore procrastinating learning Redux right now, so I figured I'd do something else. This is actually in my school notes directory, but it may end up as a blog post. Certainly sounds like it. Who knows?

read more...

tags: performance, front-end, speed, browser, client, javascript, js, css

so, tweet it?  

My Problem With React

December 28, 2015 — Zac Anger

There's this post kinda making the rounds lately. It's a nice post. Everything in there, I agree with, for sure. Especially as someone who feels a lot more comfortable with Node than with, say, Angular's mostly ungrokable API. I get why people like React. I get React. It's not exactly hard to pick up, anyway. It's very logical and intuitive. And I really do like the concepts behind React. But I still have problems with it.

read more...

tags: react, frameworks, libraries, riot, vue, js, javascript, angular, components, jsx, mithril, design

so, tweet it?  

things learned dealing with electron and the mean stack

December 16, 2015 — Zac Anger

In the interest of blogging the little things, I want to write down a couple of things I learned while struggling through my project. Nothing major, but a few things that I really had to dig to find answers to, buried way underneath unrelated issues in Github and whatnot.

read more...

tags: javascript, js, electron, angular, mean, school, css

so, tweet it?  

Finally almost done with Angular...

November 11, 2015 — Zac Anger

Look. I don't have anything against Angular on, like, a philosophical level. Or metaphysical. Or personal. I'm just not impressed. An MVC framework that makes templating easier and makes a lot of other things much more complicated? Client-side rendering? Bogging down browsers doing the heavy lifting so servers can respond a little faster? Very cool features. Very innovative. The year is 2008 and Javascript is starting to come into its own. Open source front-end libraries and frameworks are starting to pop up. Github was just founded. Angular is epic, right?

read more...

tags: javascript, school, markdown, angular, node, bitching, lots-of-bitching, god-i-bitch-a-lot

so, tweet it?  

No-Server Projects

November 07, 2015 — Zac Anger

HELLO, and welcome to another episode of Zac's Blogtime with the Blogginess!.

This week and into next week, we (the DM7 cohort in the immersive course at DevMountain) are working on our no-server projects. They are, basically, front-end based projects. Without servers. As you might've guessed from the name.

read more...

tags: javascript, angular, firebase, baas, markdown, blog, platform, editor, school, devmountain, friends

so, tweet it?  

ANGULAAAAARRRRR

November 01, 2015 — Zac Anger

...is fun. Also a pain. But fun.

I'm 239% sure I'm falling wayyy behind, but I'm also about 72% sure I started with a fairly decent headstart--not first in the cohort, for sure, but maybe around fifth. I think I'll catch up again (hush, I know it's not a race, but I don't want to be lagging) once we start back-end stuff. Maybe. Angular is nice and all, but for whatever reason I just can't seem to focus on it for long. Probably because somewhere deep down in my brain, I just can't bring myself to love the idea of that much client-side work. It feels like one of those really awesome things built by people who've never owned really shitty devices, or even average ones.

read more...

tags: javascript, bash, school, people, baas

so, tweet it?  

JAVASCRIPTSSSS

October 25, 2015 — Zac Anger

Take some concentration. Which, for me, takes a good bit of silence and, like, not needing to think about things other than what I'm trying to focus on. Kind of problematic, here. Silence and uninterrupted stretches of anything kind of don't exist when you're living with three other bachelors, and rooming with the youngest (and most talkative) of them.

Still... it's been a really crazy couple of weeks, and it's only going to get crazier. I suppose I'll be trying to move to a private room (and probably different apartment as well), come the interim... because I'm basically going to need every tiny bit of the break week(s) just to catch up.

read more...

tags: school, angular, javascript, the-struggle

so, tweet it?  

DevMountain, Week 2

October 19, 2015 — Zac Anger

That's about to start. I'm tired and I can't focus, and I'm losing a very dear friend to her demons and I can't seem to do anything about it no matter how much time I spend on the phone, because at some point I need to turn it off and try to catch up on work. She's going to die, and I'm not going to be there to stop it, and it wouldn't matter if I was because nothing would stop her except one specific asshole completely changing everything about himself and being who he must have, at some point, said he was.

So, that's going on. But on the other hand... Javascript is good. Um.

read more...

tags: people, fuck, school, javascript, goddammit

so, tweet it?  

Javascript

October 16, 2015 — Zac Anger

We're staring that today, and this is exciting. I never hated CSS until Bootstrap, but now I think I'd rather debug a hypothetical program written in both PHP and assembler than have to deal with bad CSS ever again. And I don't know any assembly languages.

So far today, everything actually makes sense. It's not easy or simple, but it's logical. I can see that mindmaps, or some similar diagraming/mapping tool, could be super useful for larger projects, though. Or even medium-ish projects. Keeping track of what's returning what to where and which functions are calling which other functions and all these things, it could very easily scramble the brains.

I've starting using Vim, too, which is another whole level of lifelong education, but I know that now that I've got the basics down, I'll probably never have trouble picking an editor again. I'm specifically using Neovim, which is not nearly as ridiculous and bloated and slow as Vim itself (thank fuck). It's taking a bit to get used to certain commands, and I'm still not exactly sure what counts as a word when I type, for example, d4e, but I'm getting there, and it's super exciting because I've finally found an editor that not only works (and works well, unlike the horde of bloated-text-editor-meets-cut-down-IDE deals), and doesn't require endless paren-mashing to work with (lookin' at you, Emacs), and has quick and easy keybinds (again, Emacs, what are you doing with yourself and why would anyone want to press seven keys simultaneously and in various combinations just to do simple things?) that mostly kind of make sense.

So that's cool. I just need to spend some time to learn how to set things up, I guess. Syntax highlighting works fine, but I have to turn it on every time I open a file. No autocompletion by default, it seems, and the indent levels are all sorts of wrong (hey four-spacers, you need to get help...).

Anyway, here's just a quick blog post. Now that we're starting to learn to program, I have a feeling I'll be too busy to think, most days, so maybe no updates for a wee bit.

tags: javascript, css, programming, vim

so, tweet it?  

Angular Meetup, 13th Oct, 2015

October 13, 2015 — Zac Anger

Notes:

Bene Brown; author on subject of empathy.

The Technical Bit

Jordan Last, speaker on Angular, client-side storage.

Problem: people want wikis, but don't like the word 'wiki.' (Yes, it's more complicated, but not so much so that a wiki wouldn't handle it).

Organization of survey site data (BYU Archaeology Dept.) &c.; Android devices, needed compat. with iOS. This fellow ended up with Ionic to handle building apps.

Okay, new question, how to work with storage? He checked out Cordova (PhoneGap), but wasn't into SQLite so much. Wanted straight-up persistant storage in the browser.

What options were there? Local, IndexedDB, WebSQL. Obviously IndexedDB isn't useful for people who want to stick with that Apple Webkit crap; Local storage is okay for... a little bit of stuff. They ended up choosing WebSQL (despite its deprecation), because they're big on relational databases and didn't want to get into Mongo or Node stuff. (Sidenote, this fellow doesn't quite grasp how the W3C works, or the problems with non-standard or deprecated technologies. Oh well.) Quick rundown on the very barest basics of ORM, aka Why We're Calling This A Model.

Looks like he's using Persistence JS. In persistence, you would save an object like, for example:

persistence.add(this)
persistence.flush()
callback && callback()

And now you have your whatsit all set. That's your save method. Then, say, thingy.save(function); and, y'know, there you go. Oh, wait. He forgot a bit about persistence. Needs schema.sync and a .config bit to get up and working.

Now, to query WebSQL in this kind of screwy setup (persistence-specific):

whatever.getStuff = function(thingPassed, maybeAnother) {
  whatever.all().filter('thingPassed', '=' whateveritis); // i suppose i missed quite a bit here
}

And, finally, deleting... which evidently should be pretty easy. Too easy to go over.

Closing points:

  • Never access the DB directly--do it through lots of Javascript and boilerplate and awkward ways.
  • Keep model-specific DB stuff with the model
  • Absolutely don't need to use persistence.js or WebSQL (thank goodness)
  • Use an ORM, silly!

Oh, and the fellow who organized this thing maybe isn't aware of other stuff going on aroud here. LunchJS would be worth looking into.

And this Jordan fellow is interesting. Bit enthusiastic, dresses half his age, but information architecture + comp sci + dev + project management = all the things I'm really interested in, mostly, pretty much.

Oh, and it was kinda neat to check out Adobe's SLC building.

tags: meetup, angular, javascript, notes

so, tweet it?  

Code Bootcamps (Comparison)

October 12, 2015 — Zac Anger

This is old, but I just found it lingering in my important docs directory in Dropbox. So... before I move it away, I figured I'd post it here in case someone is looking into these things at some point.

FWIW, I'm now officially at DevMountain (day one, yo), and I think I made the absolute best possible choice here.

read more...

tags: old, education, school, code-bootcamp, javascript, coding, programming

so, tweet it?  

I GUESS I'M LIKE IN SCHOOL AND STUFF WHAT

October 11, 2015 — Zac Anger

YESH. I'm in Provo, Utah, doing things that will eventually possibly hopefully make me skilled at something. Maybe even enough to get a job in that thing, and pay off the $$$ needed to get said education. Some quick observations:

  • Utah is flat, bare, and bland
  • Salt Lake City is more like a small town
  • Provo is not a city by any stretch of the imagination
  • People here (here at this camp, specifically) are geeks, and really hardcore about it
  • They actually get excited about things like new features/conveniences in ES6
  • I'm more behind than I'd like to be, but not as far behind as some folk
  • The Mac users will never change their ways
  • I'm going to have a grand time here, I think

read more...

tags: school, javascript, python

so, tweet it?  

Less than a week 'til school...

October 02, 2015 — Zac Anger

It's pretty crazy. I'm 99% sure I'm totally not ready, not even a little bit. As I keep saying when people ask, I know I know computers well enough, and I know I can pick things up well enough... I'm just really unfamiliar with Javascript and for some reason it doesn't stick well in my head. That's probably because I don't use it much for fun. It's not the language I'd reach for for most tasks, because (in stark contrast to most of the JS fanpersons on teh Github) I really don't believe it should be the default for a lot of things. Javascript has certainly outgrown the cheesy-animations-in-websites days, but why not use a shell script to do things that a shell script would be best for, and C to do things that should probably be done in C, and leave Javascript for doing things best handled in Javascript? Running a big, clunky, really not all that great engine just to handle using a language almost entirely based around working with the web... for doing stuff in the console? It's cool and all, yeah. I think it's really neat that I could replace most software I use with stuff installed straight from NPM--including the window manager, even. But why would I want to? Cool in theory, I guess, but if I'm using a tiling window manager the most hipster I'll get is Xmonad, and if I need an audio player chances are I'll go with (at most) MOC, not a JS clone of Mplayer.

read more...

tags: javascript, school, work, blogging, projects

so, tweet it?  

zac anger?