call api

API Call Basics

<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="body">
 <div class="p">
API calls represent specific operations that your client applications
can invoke at runtime to perform tasks, for example: <ul class="ul">
<li class="li" value="1">Query data in your organization.</li>
<li class="li" value="2">Add, update, and delete data.</li>
<li class="li" value="3">Obtain metadata about your data.</li>
<li class="li" value="4">Run utilities to perform administration tasks.</li>
</ul>
</div>
<div class="p">
Using your development environment, you can construct Web service
client applications that use standard Web service protocols to programmatically:</div>
<ul class="ul">
<li class="li" value="1">Log in to the login server (<samp class="codeph nolang">login()</samp>) and receive authentication information to be used for subsequent
calls</li>
<li class="li" value="2">Query your organization’s information (<samp class="codeph nolang">query()</samp>, <samp class="codeph nolang">queryAll()</samp>, <samp class="codeph nolang">queryMore()</samp>, and <samp class="codeph nolang">retrieve()</samp> calls)</li>
<li class="li" value="3">Perform text searches across your organization’s information
(<samp class="codeph nolang">search()</samp> call)</li>
<li class="li" value="4">Create, update, and delete data (<samp class="codeph nolang">create()</samp>, <samp class="codeph nolang">merge()</samp>, <samp class="codeph nolang">update()</samp>, <samp class="codeph nolang">upsert()</samp>, <samp class="codeph nolang">delete()</samp>, and <samp class="codeph nolang">undelete()</samp> calls)</li>
<li class="li" value="5">Perform administrative tasks, such as retrieving user information
(<samp class="codeph nolang">getUserInfo()</samp> call), changing passwords (<samp class="codeph nolang">setPassword()</samp> and <samp class="codeph nolang">resetPassword()</samp> calls), and getting the system time (<samp class="codeph nolang">getServerTimestamp()</samp> call)</li>
<li class="li" value="6">Replicate data locally (<samp class="codeph nolang">getDeleted()</samp> and <samp class="codeph nolang">getUpdated()</samp> calls)</li>
<li class="li" value="7">Obtain and navigate metadata about your organization’s
data (<samp class="codeph nolang">describeGlobal()</samp>, <samp class="codeph nolang">describeSObject()</samp>, <samp class="codeph nolang">describeSObjects()</samp>, <samp class="codeph nolang">describeLayout()</samp>, and <samp class="codeph nolang">describeTabs()</samp> calls)</li>
<li class="li" value="8">Work with workflow and approvals (<samp class="codeph nolang">process()</samp>)</li>
<li class="li" value="9">Return category groups and categories from your organization (<samp class="codeph nolang">describeDataCategoryGroups()</samp> and <samp class="codeph nolang">describeDataCategoryGroupStructures()</samp>).</li>
</ul>
<div class="p">
See <a class="xref" href="http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_calls_list.htm#topic-title">Core Calls</a>, <a class="xref" href="http://www.salesforce.com/us/developer/docs/api/Content/sforce_api_calls_list_describe.htm">Describe Calls</a>, and <a class="xref" href="http://www.salesforce.com/us/developer/docs/api/Content/utility_calls.htm#topic-title">Utility Calls</a> for complete details about each call.</div>
</div></div>

API Call Basics

API calls represent specific operations that your client applications can invoke at runtime to perform tasks, for example: ...

Plus d'infos »

Mercurial, where is your API?

<div dir="ltr" style="text-align: left;" trbidi="on">
OK, this will be short. It's nearly sleep time, and I'm donning the 
traditional flameproof ominous cloak of the Chaos Legionnaire. Ia, Ia! I've
 been doing some coding for a project called Beiti, which uses Mercurial
 in its back-end code. To work with the kivy framework for 
cross-platform compilation, Beiti is written in Python. Since Mercurial
 is also written in Python, I would have thought Mercurial would expose a
 public API as a set of Python modules I can import. I could thus use 
Mercurial from my program directly without having to resort to the 
subprocess module. No such luck. According to Mercurial's own documentation, it has an internal API in its Python modules of which it absolutely does not ever
 guarantee the API stability. The Mercurial folks explicitly document 
their lack of a public API in their own code's native language. This
 would have been kind of understandable a decade or two ago and in C, 
but today and in Python? What the hell? I understand that Mercurial is
 a major project with ongoing development and improvement, but 
seriously, not exposing a public interface in native Python just 
seems.... like the Hg devs don't really care. Come on, isn't this how 
you structure good software? Did Steve Yegge not leak an entire rant 
about how they did this at Amazon onto Google+? If you're writing 
software in Python that needs to expose a command-line interface, 
wouldn't you want to stabilize a public API, expose that in Python, and 
then just write front-end modules that reference that stable interface? 
 That would separate the evolution of your backend code from the 
interface seen by users, be we users on the command-line or users of 
your code as a library. Instead, well, I've had to go ahead and write the calls to subprocess. Sons, I am disappoint.
</div>

Mercurial, where is your API?

OK, this will be short. It's nearly sleep time, and I'm donning the traditional flameproof ominous cloak of the Chaos Legionnaire...

Plus d'infos »

The Digital Homesteader versus the Thinking Machine: a declaration of Butlerian Jihad

<div dir="ltr" style="text-align: left;" trbidi="on">
OK, now stop laughing at the title. It will soon make sense. 
There
 are several conflicting visions of what computing is and how humans 
use it at work in the world today. The operative parts of those 
visions have generated today's relevant and "hot" topics, both in 
industry and in academia, but in different parts for each vision. I 
would call these visions the Media Terminal, the Digital Homesteader, 
and the Thinking Machine. The former occurs mostly as a side-effect of 
the two latter visions, but will be explained later. 
The important thing is the ongoing battle between the Digital Homesteader and the Thinking Machine. 
The
 Digital Homesteader came first; he was the first discoverer, inventor, 
and user of all computing devices. He was the archetypical hacker and 
computing pioneer: Kernigan, Ritchie, Stallman, Guy Steele, Robin 
Milner, etc. He was often a <a href="http://en.wikipedia.org/wiki/Kibbutz#Ideology_of_the_kibbutz_movement">"kibbutznik" of a pioneer</a>:
 contributing his creations back to the overall community. He looked 
out upon the barren land, hoisted his few tools onto his shoulder, went 
down into the desert and made it bloom. Quitting metaphor, his areas of
 research and development were most commonly Systems (both 
applications-level and operating-systems level), Networking, and 
Programming Languages. The Digital Homesteader built systems and tools 
and ways to link them, because he wanted to carry his code and data on 
his back: his and no-one else's, to build a thriving home. Today he 
mostly lives in academia and in the industrial companies large enough to
 either do systems work or have research labs. 
Of course, 
there can be no ignoring the laws of ecological/economic succession. 
Once the Digital Homesteader built the world of computing, inevitably 
someone had to come along and try to own it. In this case, that someone
 looked out upon the land and saw that it was too vast. He wept and ran
 to tell his superiors, the Prophet Investors of the Promised Market, 
that the land was filled with giants who would not allow its conquest. 
And so according to the desires of the Prophetic Investors, this man 
built the Thinking Machine. He cultivated computing to be something 
into which he could pour every function of a human mind to have them 
performed better, faster, cheaper and on a larger scale than any 
flesh-creature could ever perform them. His areas have been Artificial 
Intelligence, Machine Learning, Databases, and the emerging field of 
Analytics. The Thinking Machine now grows fat on the tribute of venture
 capitalists, watching and tracking everyone who touches a computer, all
 mostly for the sake of <a href="http://theinfosphere.org/Transcript:Attack_of_the_Killer_App">marketing and sales</a>
 (the words "FIRE DIRECT MARKETING ALGORITHM!" come to mind). It plants
 its terminals in the many Silicon Valley start-ups of the world, 
claiming the power to transform "social", "Web 2.0", and "Big Data" into
 actual money with minimal actual work or use-value. We can all name 
some disciples of the Thinking Machine: Page and Brin, Zuckerberg. Yet 
it would seem half the jobs in computing today involve some service to 
It. 
Between these two, often mediating between them, stood men
 like Steve Jobs and Bill Gates. They administered the Media Terminal, a
 small capitalist town on the borderlands between the remaining 
anarchist desert of the Homesteaders and the increasingly totalitarian 
city-states of the Thinking Machine. They built their town of computing
 around personal devices used for storing small sums of personal content
 but mostly for consuming mass-produced code and data. Actually, their 
town is what remains of a larger nation now long-since gobbled up by the
 empire of the Thinking Machine, who seduced the citizenry with "web 
frontends" and "applications in the browser". The Media Terminal's 
fields of computing had been Software Engineering, Information Theory 
(for data encoding, cryptography and compression), Networking, and 
Human-Computer Interaction. 
<a href="http://en.wikipedia.org/wiki/Butlerian_Jihad">War is coming</a>
 across these lands. The first echo of the future into the past was 
Stallman founding the Free Software Foundation to guard against the 
encroachment of the Media Terminal, but over time it and the Electronic 
Frontier Foundation have had to increasingly militarize the remaining 
territories of the Digital Homsteaders to guard against the Thinking 
Machine. The Thinking Machine, for its part, <a href="http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&ved=0CEYQFjAC&url=http%3A%2F%2Ffirefly.wikia.com%2Fwiki%2FUnion_of_Allied_Planets&ei=wpU9T76IFM260QHOhZimBw&usg=AFQjCNHZjK45c0fRC1tMQVwJrO-cEodWnA">claims to offer a better life</a>, indeed a more democratic life, to those living under its purvue and government. 
I
 think my allegiance here is obvious. The real question is: how much 
power over our future comes with the various fields of expertise wielded
 by each power bloc.</div>

The Digital Homesteader versus the Thinking Machine: a declaration of Butlerian Jihad

OK, now stop laughing at the title. It will soon make sense. There are several conflicting visions of what computing is and how humans...

Plus d'infos »

This is why you can't build a Sufficiently Smart Compiler

<div dir="ltr" style="text-align: left;" trbidi="on">
I just read "Frighteningly Ambitious Startup Ideas" in detail. Do not
 regard the following as an actual start-up idea but as a sketch, if 
you will, of the massive R&D project that would actually constitute
 a Sufficiently Smart Compiler for the problem of parallelization. Start
 with a compiler that computes an effect system on an "ordinary" 
language, because, automatically, we can't force programmers to move to 
 a new language to use our Sufficiently Smart Compiler. This means that
 it tracks the read, write, alloc, free, throw, and call behavior of 
every expression/statement it compiles, aggregating them across compound
 statements. So far, we're just extending the work of some researchers
 here. (Industry has spent billions avoiding having to actually 
use better languages and better operating systems -- "web services", 
for example, are largely an attempt to shoehorn application programming
 into a universal document viewer rather than just use 9P2000/Styx for 
mounting an application directory across the network. So we can use 
ideas from the research world, but not actually make anyone else adopt 
them.) You use the effect system to form a dependency graph over 
 expressions/statements. This graph has expressions as vertices and 
data dependencies as arrows; forming it out of effect-system data gives
 you better information to build the graph out of than conventional 
data-flow analysis (which is, IIRC, intraprocedural). "Data 
dependency" of X on Y just means X comes later than Y in sequential 
execution and both have at least one effect on the same region. This 
remains in the standard realm of optimizations, pretty much. Now,
 here comes the magic. Every node/expression at the same height of 
that directed-acyclic graph depends not a wink on the others at its 
height. Each "level" of the graph can be completely parallelized, and 
its results regathered and execution serialized only when it's time to 
move on to the next level of the graph. Our compiler is now somewhat smart. I also recommend employing a deterministic-parallel-execution framework/library to cover our asses. Here's the tricky bit: which nodes of that graph are worth
 parallelizing? Spawning threads, even green threads, is expensive. 
We need to figure out what expressions/statements are computationally 
expensive enough to be worth forking now and joining later. I've never 
 heard of a compiler that will do Big-O complexity analysis for the 
programmer, at least not without dependent types (static analysis 
dependent upon and capable of predicting dynamic (run-time) values). We
 could use hand-written annotations/pragmas to determine what's 
expensive, but then we're putting effort back on our user instead of 
acting like a magic genie that solves all their problems without their 
having to think. Again, we could use a genetic algorithm to decide 
where to parallelize, but that's obtrusive to the user (spending 
expensive developer time) instead of transparent (spending cheap 
computer time). And, of course, none of this gets us around the problem that much/most
 actual code in non-functional languages is written in an effectful, 
inherently-sequential style when it could otherwise be stateless/pure 
and embarrassingly parallel. All we've built is a compiler 
capable of spotting the good parallelization opportunities and taking 
them without outside human direction. We already had to build two 
kinds of compiler magic, one based on the other, and then employ either
 some new form of static performance/complexity analysis, some funky 
heuristics, or even a genetic algorithm to figure out where to allocate
 our resources. The sufficiently smart compiler can exist, but it carries such a horrific
 analytical burden that it would rarely, if ever, get around to the 
actual business of generating code. And then you'd have to turn it 
into an actual business treating software as a product ("selling 
smells")! Or you could build it as a research project, in which case 
you're likely to spend the rest of your life on the damn thing from 
having to "pivot" for grant funding every so often.</div>

This is why you can't build a Sufficiently Smart Compiler

I just read "Frighteningly Ambitious Startup Ideas" in detail. Do not regard the following as an actual start-up idea but as ...

Plus d'infos »

Programming is hard, which is why I don't want to do it

<div dir="ltr" style="text-align: left;" trbidi="on">
It's not been about 9 months that I've been a "real" programmer, working
 for an actual boss writing code someone actually uses instead of being a
 student or hobbyist, working on classes, research, or a hobby project. 
 It's been eye-opening: industrial coding is very different from hobby 
coding, class coding or research coding. 
 
Class coding involves very small tasks that map almost perfectly onto 
known algorithmic or computer-scientific problems.  You are told to 
write a Sudoku solver using certain kinds of heuristic searches, and you
 thus know to write a heuristic search algorithm with a certain set of 
heuristics and optimizations.  When it's done, you just write a tiny bit
 of code that applies the heuristic search to Sudoku solving.  Done. 
 
Research coding can get very involved and very dirty, because it's 
fundamentally about inventing and/or implementing an entirely new 
solution to a previously-unsolved problem.  It's an act of invention, 
and if you have to make a publication deadline, you probably won't have 
the time to make the code look nice.  You design the algorithm, you 
prove it works, and you crank out a quick-and-dirty implementation.  
Sometimes you also take the opposite approach: quickly-and-dirtily 
design and implement an algorithm, test it, and see if you can construct
 a proof that it's a real solution to your problem (I can hear 
researcher colleagues crying out in pain, but when you don't know if 
your problem is solvable, this helps you find a solvable case).  Either 
way, you usually only write one algorithm, or a few algorithms, devoted 
to solving a particular problem about which you definitely know. 
 
Industrial coding, on the other hand, is quite different.  It's always
 very involved and very dirty, but it rarely involves anything of 
fundamental computational or intellectual difficulty.  Instead, its 
difficulty arises from the sheer quantity of incidental state and 
details I have to hold in my head to do it.  My typical workday, right 
now, involves opening two iTerm windows with 3 tabs each to run and 
monitor two Ruby on Rails applications, an iTerm window of one tab to 
run memcached, two Mac Console windows to read the two applications' 
debug logs, a Firefox window with at least two tabs to run the apps, and
 two TextMate windows that each have a tab open for every source file 
I'm editing at the moment.  Count them up: a minimal workflow 
involves opening a minimum of eight windows with a combined minimum of 
ten tabs.  A more realistic workflow also involves having Apple Mail 
open and about eight TextMate tabs, for a real total of nine windows and 16 tabs open at once, just to do my day job. 
 
The actual product is just a couple of internal applications for 
fetching and parsing XML feeds from a content source, then serving the 
date back up to a user's web browser in JSON form or in HTML Rails 
views.  There is nothing inherently difficult or complex about this.  No
 computer scientist would dare publish a paper about these applications,
 they'd be laughed out of the research community and told to go back "to
 industry" from whence they came.  Yet actually writing these 
applications depends on a medley of technologies, domain expertise, 
experimentation to understand the data formats being sent to us, and 
intuition to estimate user expectations. 
 
Yet I find this kind of coding much harder than working on research or 
on a hobby project.  My brain has always afflicted me with ADHD 
tendencies: I get distracted somewhat too easily, unless I'm truly 
immersed in something, and context-switching has a high cost once I am
 immersed.  I actually find it easier to invent an algorithm for doing 
type-inference over a Damas-Milner-style type system with subtyping 
rules than to hold nine windows and 16 tabs of Ruby on Rails 
data-serving apps in mind at once.  I have a much easier time cutting 
away the impurities from the ore and forging a single, elegant piece of 
steel than dealing with myriad layers of everyday concrete. 
 
Hence the title: real programming is hard.  I don't find it hard in a 
"fundamental" way, but in a this-is-difficult-for-my-brain way.  Hence 
the title: I have to target myself, for my future, towards the kind of 
inherently-hard problems I'm actually good at addressing.  The funny 
thing is, I needed at least this minimal time "in industry" to find that
 out, because before you graduate university, everyone does Computer 
Science.  Only after graduating did I find out that most of my peers 
have a much easier time doing real, useful industrial programming, while
 I more greatly enjoy the Computer Science we all fought our way through
 back in school.
</div>

Programming is hard, which is why I don't want to do it

It's not been about 9 months that I've been a "real" programmer, working for an actual boss writing code someone actuall...

Plus d'infos »

Lambdas-as-capabilities: a systems programming trick

<div dir="ltr" style="text-align: left;" trbidi="on">
Here's a bit of a trick or a "programming pearl" to show why high-level 
systems programming languages are useful.  The trick uses existential 
types/packages to securely and easily enable a kind of system call API 
that most operating systems spend a lot of effort to support.  This only works in an advanced language like Deca, or even exactly and
 only in Deca where the abstracted data in an existential package is 
unboxed. 
 
You take an existential package describing an OS object and functions 
available on it, you package it with some constant value like 
0xdeadbeef, and then you encrypt the whole thing using a key only the 
kernel knows. You then hand the resulting blob of bytes to the 
userspace applications as a cryptographically-based capability.  
User-space knows the existential type and the size-in-memory of the 
capability it has received, but it can't decrypt the capability and 
can't pierce the existential veil. 
 
Your OS's system-call API can thus support capability-based naming and security.
</div>

Lambdas-as-capabilities: a systems programming trick

Here's a bit of a trick or a "programming pearl" to show why high-level systems programming languages are useful. The trick...

Plus d'infos »

A letter to the Trichordist, on why I sometimes pirate

<div dir="ltr" style="text-align: left;" trbidi="on">
Ok, so I'm speaking here as 
one of those damn kids who's been pirating lots of stuff since forever. 
 I just read The Trichordist's intelligent and engaging <a href="http://thetrichordist.wordpress.com/2012/06/18/letter-to-emily-white-at-npr-all-songs-considered/" target="_blank">Letter to Emily White at NPR's All Songs Considered</a>. 
 My trouble, as a pirate and a paying consumer and a downloader of 
music legally put up for free download by artists, is not with the 
artists at all. It's with the middle-men, and I don't mean the 
middle-men stiffing the artist. As an aside on that subject, 
the artist apparently (according to this blog) gets about $0.30 per song
 per download. At the very least, I pay about $0.99 per song on iTunes.
 If I buy an album of about 12 songs for $20, I'm actually paying more 
like $1.50 per song. So there's a huge gap between the prices I get 
charged for music, and what goes back to the artist, even when we've cut
 out as much middle-man as is apparently possible. I will note that 
with artists like Jonathan Coulton who maintain their own 
downloadable-music stores (or authors like Diane Duane who sell their 
own e-books, or Kickstarter projects), I gladly chip in my few dollars 
for the work. No, my problem is with the middle-men 
continually trying to insist that each song is a rare gem to be kept 
under strict supervision and control, even after its purchase, rather 
than a commodity to be bought and consumed. The artists I patronize 
have almost uniformly learned one lesson: DO NOT PUT DRM ON YOUR 
FREAKING MUSIC! And usually, they've also learned a second lesson, 
which is: KEEP A FREAKING ARCHIVE. This is the core message of the Free
 Culture movement: once I have bought a piece of media (e-book, song of 
music, movie, television episode, video game, whatever), on the artist's
 terms, paying the artist for their good and worthy work, it becomes mine. 
Don't tell me that I can't back it up with the rest of my personal data,
 that it will suddenly stop working next year, or that you're going to 
replace the format and make me shell out money for a re-made, "updated" 
version of something I already own quite legally. Funny thing, 
most actual artists I know or patronize have no problem with that. They
 don't throw draconian restriction schemes on their media, and in 
return, as a matter of conscience, I don't pirate from them. Ever. 
It's an easier combination of convenience and morality to pay, when I'm 
paying for a CD or MP3 files that I can save as I please rather than an 
encryption-locked DVD or game cartridge playable only on hardware that 
you will stop supporting next year, leaving my rightfully-bought media 
to rot for sheer age. Middle-man products like Steam even manage to 
give me, the customer, some additional convenience as compensation for 
allowing their copyright-protection scheme onto my computer, and they 
give good sale-prices too. As a result I own many more Steam games, 
bought indulgently on sale, than I actually have time to play. 
Oh, and stop messing around with international licensing rights, and 
stop deliberately bilking international buyers. I don't want to hear 
that I need to pay $1500 for a ticket to Europe, Japan, China, India, 
Africa, or Israel in order to buy your $20 CD or $50 DVD, nor that when I
 do manage to buy an import it won't play on my equipment, nor that 
you've decided you can price-gouge foreigners (looking at you, anime 
export industry charging $40 for a DVD with three half-hour episodes of 
television on it) on the localized editions. I buy legally whenever I can keep what I buy. I pirate when I can't.  Because otherwise, <a href="http://xkcd.com/488/" target="_blank">you'll be a criminal either way.</a></div>

A letter to the Trichordist, on why I sometimes pirate

Ok, so I'm speaking here as one of those damn kids who's been pirating lots of stuff since forever. I just read The Trichordist...

Plus d'infos »

call api

Popular Posts

Qui êtes-vous ?

You can also receive Free Email Updates:

Archives du blog

API Call Basics

Mercurial, where is your API?

The Digital Homesteader versus the Thinking Machine: a declaration of Butlerian Jihad

This is why you can't build a Sufficiently Smart Compiler

Programming is hard, which is why I don't want to do it

Lambdas-as-capabilities: a systems programming trick

A letter to the Trichordist, on why I sometimes pirate