elwinar

package main

import (
	"unicode"
)

// ToSnake convert the given string to snake case following the Golang format:
// acronyms are converted to lower-case and preceded by an underscore.
func ToSnake(in string) string {
	runes := []rune(in)

akmalxxx

import android.content.Context;
import android.content.res.TypedArray;
import android.util.AttributeSet;
import android.support.v7.widget.RecyclerView;
import android.support.v7.widget.LinearLayoutManager;
import android.view.View;
import android.graphics.Rect;
import android.graphics.drawable.Drawable;
import android.graphics.Canvas;

gabrielemariotti

You can use this class to realize a simple sectioned RecyclerView.Adapter without changing your code.

The RecyclerView should use a LinearLayoutManager. You can use this code also with the TwoWayView with the ListLayoutManager (https://github.com/lucasr/twoway-view)

This is a porting of the class SimpleSectionedListAdapter provided by Google

Example:

mattes

if _, err := os.Stat("/path/to/whatever"); os.IsNotExist(err) {
	// path/to/whatever does not exist
}

if _, err := os.Stat("/path/to/whatever"); !os.IsNotExist(err) {
	// path/to/whatever exists
}

alexfu

/*
 * Copyright (C) 2014 The Android Open Source Project
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software

jackgris

buildscript {
    repositories {
        mavenCentral()
        maven {
            url 'https://oss.sonatype.org/content/repositories/snapshots/'
        }
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:0.9.+'
        classpath 'com.squareup.gradle:gradle-android-test-plugin:0.9.1-SNAPSHOT'

hvoecking

// Traverses an arbitrary struct and translates all stings it encounters
//
// I haven't seen an example for reflection traversing an arbitrary struct, so
// I want to share this with you. If you encounter any bugs or want to see
// another example please comment.
//
// The MIT License (MIT)
//
// Copyright (c) 2014 Heye Vöcking
//

jamesob

Most developers would agree that, all other things being equal, a synchronous program is easier to work with than an asynchronous one. The logic for this is pretty clear: one flow of execution is easier for the human mind to simulate than n concurrent flows.

After doing two small projects in node.js (one of which is here -- ready for the blinding flurry of criticism), there's one question that I can't shake: if asynchronicity is an optimization (that is, a complexity introduced for the sake of performance), why would people, a priori, turn to a framework that imposes it for everything? If asynchronous code is harder to reason about, why would we elect to live in a world where it is the default?

It could be argued pretty well that the browser is a domain that inherently lends itself to an async model, but I'd be very curious to hear a defense of "async-first" thinking for problems that are typically solved on the server-side. When working with node, I've noticed

rbishop

Carl Hewitt on Actors

Actor - Fundamental unit of computation, a computation model - not just a form of concurrency

An Actor has three essential elements:

• 1 - Processing - you have to get something done
• 2 - Storage - you have to be able to remember things
• 3 - Communication

chilts

var request = require('request');
var unzip   = require('unzip');
var csv2    = require('csv2');

request.get('http://s3.amazonaws.com/alexa-static/top-1m.csv.zip')
    .pipe(unzip.Parse())
    .on('entry', function (entry) {
        entry.pipe(csv2()).on('data', console.log);
    })
;