De utrolige pengemaskinene

Vi må ikke la fakta og fornuft ødelegge troen på offentlig eierskap i kraftbransjen. 

Vannkraft er en fantastisk pengemaskin. Det sier seg selv at kraftstasjoner som generer klingende mynt i kassa fra fosser og stryk nesten uten kostnad, må være ekstremt lønnsomt. Marginene innen vannkraft er så rå at det vil være ren idioti å tillate kommuner og fylkeskommuner å selge seg ut av denne eventyrindustrien.

Nå er det jo slik at retten til å hente ut disse marginene har en verdi. Finansmarkedet vil normalt verdsette verdiene slik at avkastningen på vannkraft ikke skiller seg nevneverdig fra andre investeringer.

Vi bør imidlertid ikke godta dette faktumet uten videre. Utgangspunktet er jo at det offentlige bør ha kontroll over alle vannkraftressurser i landet. Da passer det dårlig at vannkraft verken er mer eller mindre lønnsomt enn andre investeringer. I så fall ville det jo gitt langt mer forutsigbare utbytter om kommunene bare solgt vannkraften og satt pengene i mindre risikable indeksfond.

For å få terrenget til å stemme litt bedre med kartet, har jeg derfor tatt med kursutviklingen til de to kraftselskapene som er notert på Oslo Børs.

I figuren ser vi at Arendals Fossekompani har slått børsen! Vi ser også at pengemaskinen Hafslund har tapt i forhold til børsen siden 2003. Her skulle jeg gjerne innvendt at Hafslundkursen ikke er utbyttejustert, men det er den dessverre. Slik sett var det kanskje litt dumt at jeg tok med Hafslund her.





Siden Hafslund-eksemplet avviser teorien om evig pengemaskin, foreslår jeg at vi fokuserer på Arendals Fossekompani. Det som er spesielt med dette selskapet er at det er noe så uvanlig som et privat kraftselskap. Arendals kjøpte fallrettigheter før konsesjonsloven. “Forbudet” mot privat eierskap gjelder derfor ikke for disse kraftstasjonene.

Vi ser at Arendals har slått indeksen, men forskjellen er ikke stor nok til å fastslå om det skyldes tilfeldigheter. Det viktigste er imidlertid at denne observasjonen bekrefter konklusjonen vi ønsker.

Det finnes imidlertid også en del andre plagsomme eksempler på at kraftselskap ikke er pengemaskiner. Lyse Energi har tapt mye på Altibox og oljeinvesteringer. For Nordkraft har urealistiske planer om småkraftutbygging ført til store nedskrivninger. Troms Kraft tapte over 1,5 milliarder på Kraft og Kultur og har ellers vist en imponerende evne til å plukke tapsprosjekter. Hafslund har også tapt store beløp i det siste, blant annet på avfallshåndtering og solenergi.

For at vi ikke helt skal miste fokus på at kraftinvesteringer alltid er lønnsomme vil jeg her påberope irrelevans-argumentet. Disse eksemplene gjelder jo i mange tilfeller offentlig eide kraftselskaper hvor eierne ikke har vært i stand til å utøve godt eierskap. De har derfor overlatt for mye til administratorer som har vært mer opptatt av å bygge imperier enn å utvikle vannkraften.

Dette er jo noe helt annet enn offentlige eide kraftselskaper der driften over tid utvikler seg til en uendelig pengemaskin. Det er jo pengemaskiner vi ønsker, ikke tapssluk. For at konklusjonen vår skal stemme foreslår jeg derfor at vi overser alle disse eksemplene.

Konklusjonen blir dermed som bestilt; vannkraften bør eies og drives av det offentlige. Staten bør fortsatt forby privat eierskap gjennom konsesjonslovgivningen. På den måten sikrer en at tapene finansieres av de velfylte kommunekassene. Det er jo også godt kjent at disse har både evne og vilje til å bære den betydelige finansielle risikoen det er å eie store aksjeposter i enkeltselskap.

How to send and receive STOMP message in JBoss 7.2

The following code is an example of how we can send and receive a stomp message with JBoss 7.2.

package org.meveo.util;

import java.io.InputStream;
import java.io.OutputStream;
import java.net.Socket;
import java.util.Properties;

import javax.naming.InitialContext;

/**
* @author Edward P. Legaspi
* @since Nov 4, 2013
**/
public class StompUtil {

private static final String END_OF_FRAME = "\u0000";
private static final String USERNAME = "guest";
private static final String PASSWORD = "guest";
private static String HOST = "localhost";
private static String STOMP_VERSION = "1.1";

public static void sendMessage(String destinationQueue, String message)
throws Exception {
sendMessage(STOMP_VERSION, HOST, destinationQueue, USERNAME, PASSWORD,
message);
}

public static void sendMessage(String destinationQueue, String username,
String password, String message) throws Exception {
sendMessage(STOMP_VERSION, HOST, destinationQueue, username, password,
message);
}

public static void sendMessage(String stompVersion, String url,
String destinationQueue, String username, String password,
String message) throws Exception {
if (url != null && !url.isEmpty()) {
HOST = url;
}
// Step 1. Create a TCP socket to connect to the Stomp port
Socket socket = new Socket("localhost", 61613);

// Step 2. Send a CONNECT frame to connect to the server
String connectFrame = "CONNECT\n" + "accept-version:" + stompVersion
+ "\n" + "host:" + HOST + "\n" + "login:" + username + "\n"
+ "passcode:" + password + "\n" + "request-id:1\n" + "\n"
+ END_OF_FRAME;
System.out.println("sending message to queue=" + destinationQueue);
sendFrame(socket, connectFrame);

String response = receiveFrame(socket);
System.out.println("response: " + response);

// Step 3. Send a SEND frame (a Stomp message) to the
// jms.queue.exampleQueue address with a text body
String queueMessage = "SEND\n" + "destination:" + destinationQueue
+ "\n" + "\n" + message + END_OF_FRAME;
sendFrame(socket, queueMessage);
System.out.println("Sent Stomp message: " + message);

// Step 4. Send a DISCONNECT frame to disconnect from the server
String disconnectFrame = "DISCONNECT\n" + "\n" + END_OF_FRAME;
sendFrame(socket, disconnectFrame);

// Step 5. Slose the TCP socket
socket.close();
}

private static void sendFrame(Socket socket, String data) throws Exception {
byte[] bytes = data.getBytes("UTF-8");
OutputStream outputStream = socket.getOutputStream();
for (int i = 0; i < bytes.length; i++) {
outputStream.write(bytes[i]);
}
outputStream.flush();
}

private static String receiveFrame(Socket socket) throws Exception {
InputStream inputStream = socket.getInputStream();
byte[] buffer = new byte[1024];
int size = inputStream.read(buffer);

byte[] data = new byte[size];
System.arraycopy(buffer, 0, data, 0, size);

String frame = new String(data, "UTF-8");
return frame;
}

}
And below is how you would call the utility:
StompUtil.sendMessage("jms.queue.test", "hello world!");
To receive the message
@Inject
@TestQueue
private Queue testQueue;

@Inject
private Connection connection;
//......
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageConsumer consumer = session.createConsumer(testQueue);

connection.start();

TextMessage messageReceived = (TextMessage) consumer.receive(5000);
System.out.println("Received JMS message: " + messageReceived.getText());
The producer class
public class Resources {

@Resource(mappedName = "java:/ConnectionFactory")
private ConnectionFactory connectionFactory;

@Resource(mappedName = "queue/test")
@TestQueue
private Queue testQueue;

@Produces
public Connection createConnection() throws JMSException {
return connectionFactory.createConnection();
}

public void closeConnection(@Disposes Connection conn) throws JMSException {
conn.close();
}

@Produces
@TestQueue
public Queue getTestQueue() {
return testQueue;
}

}

Selg Statoil

Professor Øystein Noreng argumenterer i DN onsdag at regjeringen ikke bør selge seg ned i Statoil fordi de vil miste kontroll med selskapet og at hovedkontoret kan bli flyttet.

Med 33 % minoritetsaksjonærer er det ingen politisk kontroll. Selskapet styres ved stemmegivning på generalforsamling. Statoil kan ikke gi særfordeler til staten. Virksomheten skal drives ut fra bedriftsøkonomiske hensyn.

Staten har derfor ikke reel politisk innflytelse. Når overstyrte staten sist ledelsen? Statoil skal drive kommersiell virksomhet, og statens viktigste bidrag er å velge et kompetent styre til å utføre denne jobben.

Det profesjonelle eierskapet har vært lønnsomt for aksjonærene. Mulighetene til politisk styring har imidlertid forsvunnet. Det er ingen kontroll å miste. Noreng har kanskje rett i at “Formålet med selskapet har vært å utvikle norsk sokkel fremfor å tjene penger”, men den tiden er forbi for lenge siden.

I Statoils norske virksomhet finnes det åpenbart mye verdifull kompetanse som ikke kan flyttes. Det er imidlertid liten grunn til våkenetter over at noen få direktører og stabsmedarbeidere kanskje kan få adresse London eller New York. Selskapet vil bli drevet ut fra bedriftsøkonomiske prinsipper uansett.

Forskningen viser at internasjonalt eierskap øker kunnskapsoverførsel og innovasjon, og bidrar til økt verdiskapning. Frykten for utlendinger er forståelig men ubegrunnet. Statoil hadde sett ganske annerledes ut i dag om alle land tenkte på denne måten. Staten tar en enorm risiko ved å eie Statoil. BP-aksjen ble mer enn halvert etter gulfkatastrofen. Selg Statoil og sett pengene i oljefondet.

U.S. Inflation Expectations: Low, But Rising

There's been a lot of talk lately about the threat of global deflation. According to Christine Lagarde, Managing Director of the IMF:
“With inflation running below many central banks’ targets, we see rising risks of deflation, which could prove disastrous for the recovery.”
And closer to home:
Ms Lagarde’s comments were echoed by Charles Evans, president of the Chicago Fed. “The recent news on inflation has not been good,” he said in a speech on Wednesday. “Inflation is too low and is running well below the FOMC’s 2 per cent target.”
Inflation in the U.S. is indeed running below target, but what about inflation expectations? Here are some market-based measures of U.S. inflation expectations (based on TIPS spreads) for two, five, and ten years out:


According to this data, inflation expectations in the second quarter of 2013 declined significantly at all horizons. The sudden jump down in expectations in the summer corresponds with the sudden rise in Treasury yields associated with the so-called "taper tantrum" following the June 19 FOMC meeting.

But it is interesting to note that immediately after the taper tantrum, inflation expectations recovered and stabilized, albeit at low levels (especially at the two and five year horizons). At the same time, nominal yields rose and remain elevated (with the 10 year hovering at or just below 3%).

What is even more interesting the reaction of inflation expectations after the December 2013 FOMC meeting, where the taper was actually implemented (the timing of which came as a surprise to most market participants). Short-run inflation expectations, in particular, appear to be on an upward trajectory. The effect is less evident at longer horizons.

I'm not going to offer any interpretation of what economic forces are at play here (I'll leave it up to you to offer your take on things in the comments section). One thing I can say though is that this data will provide at least a small measure of comfort to Fed policy makers concerned about the threat of deflation.

How to create an xsd and xml data from model entity in java

The following code will show how to generate a xsd base on a given model and a sample xml with data.

Let's assume you have a CustomerList model, which is an array of Customer.

JAXBContext context;
try {
context = JAXBContext.newInstance(CustomerList.class);
context.generateSchema(new SchemaOutputResolver() {
@Override
public Result createOutput(String namespaceURI,
String suggestedFileName) throws IOException {
File file = new File("c://temp//customer.xsd");
StreamResult result = new StreamResult(file);
result.setSystemId(file.toURI().toURL().toString());
return result;
}
});
Marshaller m = context.createMarshaller();
m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE);
m.marshal(listToExport, new FileOutputStream(
"c://temp//customers.xml"));
} catch (JAXBException e) {
e.printStackTrace();
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}

Next is how are we going to read a java object from xml file. Let the code explain :-)
JAXBContext jaxbContext = JAXBContext.newInstance(CustomerList.class);
InputStream is = getClass().getClassLoader().getResourceAsStream(
"customer.xml");
Unmarshaller jaxbUnmarshaller = jaxbContext.createUnmarshaller();
CustomerListmessages = (CustomerList) jaxbUnmarshaller.unmarshal(is);

Useful tool in transforming an xml to xsd:
http://www.freeformatter.com/xsd-generator.html#ad-output

How to create size-rotating-file handler in JBoss 7.2 using CLI

There are times when we require a size-rotating-file handler over the default periodic-rotating-file handler. Simply changing the properties in standalone.xml won't do because it will cause synch problem with logging.properties. So to do so we need to execute a series of JBoss cli commands.

First you need to run: jboss_home/standalone/bin/jboss-cli.sh and connect.


//remove the default file handler
/subsystem=logging/periodic-rotating-file-handler=FILE:remove

//create the new file handler
/subsystem=logging/size-rotating-file-handler=FILE:add(file={"path"=>"server.log", "relative-to"=>"jboss.server.log.dir"})
/subsystem=logging/size-rotating-file-handler=FILE:write-attribute(name="autoflush", value="true")
/subsystem=logging/size-rotating-file-handler=FILE:write-attribute(name="level", value="WARN")
/subsystem=logging/size-rotating-file-handler=FILE:write-attribute(name="append", value="true")
/subsystem=logging/size-rotating-file-handler=FILE:write-attribute(name="max-backup-index", value="10")
/subsystem=logging/size-rotating-file-handler=FILE:write-attribute(name="rotate-size", value="5000k")

References:
https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Administration_and_Configuration_Guide/Configure_a_Periodic_Log_Handler_in_the_CLI1.html
https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Administration_and_Configuration_Guide/Sample_XML_Configuration_for_a_Size_Log_Handler.html

What is the OLG model of money good for?

I want to say a few things in response to Brad DeLong's post concerning the usefulness of overlapping generations (OLG) models of money (and on the value of "microfoundations" in general). Let's start with this:
As I say over and over again, forcing your model to have microfoundations when they are the wrong microfoundations is not a progressive but rather a degenerative research program.
Why is he saying this "over and over again" and to whom is he saying it? What if I had said "As I say over and over again, forcing your model to have hand-waving foundations when they are the wrong hand-waving foundations is not a progressive but rather degenerative research program."? That would be silly. And the quoted passage above is just as silly.

A theory usually take the following form: given X, let me explain to you why Y is likely to happen. The "explanation" is something that links X (exogenous variables) to Y (endogenous variables). This link can be represented abstractly as a mapping Y = f(X).

There are many different ways to construct the mapping f. One way is empirical: maybe you have data on X and Y, and you want to estimate f. Another way is to just "wave your hands" and talk informally about the origins and properties of f. Alternatively, you might want to derive f based on a set of assumed behavioral relations. Or, you may want to deduce the properties of f based on a particular algorithm (individual optimization and some equilibrium concept -- the current notion of "microfoundations"). Some brave souls, like my colleague Arthur Robson, try to go even deeper--seeking the biological foundations for preferences, for example.

I don't think we (as a profession) should be religiously wedded to any one methodological approach. Which way to go often depends on the question being asked. Or perhaps a particular method is "forced" because we want to see how far it can be pushed (the outcome is uncertain -- this is the nature of research, after all). And I'm not sure what it means to have the "wrong" microfoundations. (Is it OK to have the wrong "macrofoundations?") Any explanation, whether expressed verbally or mathematically, is based on assumption and abstraction. Something "wrong" can always be found in any approach -- but this is hardly worth saying--let alone saying "over and over again."

Now on to the OLG model of money. Here is DeLong again:
Yes, it seemed to me that handwaving was not good. But saying something precise and false–that we held money because it was the only store of value in a life-cycle context, and intergenerational trade was really important–seemed to me to be vastly inferior to saying something handwavey but true–that holding money allows us to transact not just with those we trust to make good on their vowels but with those whom we do not so trust, and that as a result we can have a very fine-grained and hence very productive division of labor.
Not many people know this, but the OLG model (invented first by Allais, not Samuelson) is just an infinite-horizon version of Wicksell's triangle. The following diagram depicts a dynamic version of the triangle. Adam wants to eat in the morning, but can only produce food at night. Betty wants to eat in the afternoon, but can only produce food in the morning. Charlie wants to eat at night, but can only produce food in the afternoon (assume food is nonstorable).


In the model economy above, there are no bilateral gains to trade (if we were to pair any two individuals, they would not trade). Sometimes this is called a "complete lack of coincidence of wants." There are, however, multilateral gains to trade: everyone would be made better off by producing when they can, and eating when they want to (from each according to their ability, to each according to their need).

Consider an N-period version of the triangle above. Adam still wants bread in period 1, but can only produce bread in period N. Now send N to infinity and interpret Adam as the "initial old" generation (they can only produce bread off into the infinite future). Interpret Betty as the initial young generation (they produce output in period 1, but want to consume in period 2), and so on. Voila: we have the OLG model.

I've always considered Wicksell's triangle a useful starting point for thinking about what might motivate monetary trade (sequential spot market trade involving a swap of goods for an object that circulates widely as an exchange medium). In particular, while there is an absence of coincidence of wants, we can plainly see how this does not matter if people trust each other (a point that DeLong alludes to in the quoted passage above). If trust is lacking--assume, for example, that only Adam is trustworthy--then Adam's IOU (a claim against period N output) can serve as a monetary instrument, permitting intertemporal trade even when trust is in short supply.

An exchange medium is valued in an OLG model for precisely the same reason it is in the Wicksell model or, for that matter, any other model that features a limited commitment friction. So if anyone tries to tell you that the OLG model of money relies on money being the only store of value to facilitate intergenerational trade, you now know they are wrong. The overlapping generation language is metaphorical.

In any case, as it turns out, the foundation of monetary exchange relies on something more than just a lack of trust. A lack of trust is necessary, but not sufficient. As Narayana Kocherlakota has shown (building on the work of Joe Ostroy and Robert Townsend) a lack of record-keeping is also necessary to motivate monetary exchange (since otherwise, credit histories with the threat of punishment for default can support credit exchange even when people do not trust each other).

Also, as I explain here, a lack of coincidence of wants seems neither necessary or sufficient to explain monetary exchange. (Yes, I construct a model where money is necessary even when there are bilateral gains to trade.)

Are any of these results interesting or useful? Well, I find them interesting. And I think the foundations upon which these results are based may prove useful in a variety of contexts. We very often find that policy prescriptions depend on the details. On the other hand, I have nothing against models that simply assume a demand for money. These are models that are designed to address a different set of questions. Sometimes the answers to these questions are sensitive to the assumed microstructure and sometimes they are not. We can't really know beforehand. That's why it's called research.

Finally, is a "rigorous microfoundation" like an OLG (Wicksell) model really necessary to deduce and understand the points made above? I suppose that the answer is no. But then, it's also true that motor vehicles are not necessary for transport. It's just that using them let's you get there a lot faster and more reliably.