Access Token換掉就可以用了
const querystring = require('querystring'); | |
const axios = require('axios'); | |
function getAuthLink(clientId, redirectUrl, state) { | |
const data = { | |
response_type: 'code', | |
client_id: clientId, | |
redirect_uri: redirectUrl, | |
scope: 'notify', | |
state, |
@interface UIPreviewForceInteractionProgress : NSObject | |
- (void)endInteraction:(BOOL)arg1; | |
@end | |
@interface UIPreviewInteractionController : NSObject | |
@property (nonatomic, readonly) UIPreviewForceInteractionProgress *interactionProgressForPresentation; |
When Swift was first announced, I was gratified to see that one of the (few) philosophies that it shared with Objective-C was that exceptions should not be used for control flow, only for highlighting fatal programming errors at development time.
So it came as a surprise to me when Swift 2 brought (What appeared to be) traditional exception handling to the language.
Similarly surprised were the functional Swift programmers, who had put their faith in the Haskell-style approach to error handling, where every function returns an enum (or monad, if you like) containing either a valid result or an error. This seemed like a natural fit for Swift, so why did Apple instead opt for a solution originally designed for clumsy imperative languages?
I'm going to cover three things in this post:
@import WatchKit; | |
@interface CachingInterfaceController : WKInterfaceController | |
- (void)updateLabel:(WKInterfaceLabel *)label withString:(NSString *)string; | |
- (void)updateLabel:(WKInterfaceLabel *)label asHidden:(BOOL)hidden; | |
- (void)updateImage:(WKInterfaceImage *)image withImageNamed:(NSString *)imageName; | |
- (void)updateImage:(WKInterfaceImage *)image withBaseNameForAnimation:(NSString *)baseName withRange:(NSRange)range duration:(NSTimeInterval)duration repeatCount:(NSInteger)repeatCount; | |
- (NSString *)currentImageNameForImage:(WKInterfaceImage *)image; |
So you got your u-blox GPS and wired it up only to look at it struggling to get a valid fix? Under less than ideal conditions, it can take a better part of half an hour. That's because unlike your smartphone GPS, it doesn't have the luxury of having downloaded all the auxiliary navigation data (almanacs and the lot) out-of-band, via fast mobile connection. Instead it relies on the satellite's signal itself, which is being transmitted to you at meager 50 bits per second (I'm not missing "kilo" there, it's three orders of magnitude slower than your 2G GPRS connection).
Luckily, the u-blox receivers are fitted with what the company calls "AssistNow" capability and it does exactly the same thing your iPhone does - feeds the GPS with pre-downloaded almanacs, speeding up the acquisition process to mere seconds.
In principle, the process looks easy enough - we just need to download the data, and then push them to the receiver. Sadly, the AssistNow documentat
# Install | |
# via http://askubuntu.com/questions/510056/how-to-install-google-chrome | |
wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add - | |
sudo sh -c 'echo "deb http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google-chrome.list' | |
sudo apt-get update | |
sudo apt-get install google-chrome-stable | |
# Update |
This is the general instructions for how to get a pebble watch to talk to an ESP8266 and turn NeoPixels different colours.
Video: https://www.youtube.com/watch?v=BeIQ47WBVXs
- Pebble watch
- ESP8266 ESP-01