Finding a remote developer

lrcchen 2022-12-16 01:17:47

Job description

The ideal candidate will be responsible for developing high-quality applications remotely. They will also be responsible for designing and implementing testable and scalable code.

 

Responsibilities

  • Develop quality software and web applications
  • Analyze and maintain existing software applications
  • Design highly scalable, testable code
  • Discover and fix programming bugs
  • Document writing

 

Qualifications

  • Bachelor's degree or equivalent experience in Computer Science or related field
  • Development experience with programming languages, C# is preferred
  • SQL database or relational database skills
  • Web Design skills
  • Fluent in English is a must

Please send email to info@powteck.com if you are interested in this job.

...全文
1092 回复 打赏 收藏 转发到动态 举报
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复
Practical Quantum Computing for Developers: Programming Quantum Rigs in the Cloud using Python, Quantum Assembly Language and IBM QExperience By 作者: Vladimir Silva ISBN-10 书号: 1484242173 ISBN-13 书号: 9781484242179 Edition 版本: 1st ed. 出版日期: 2018-12-13 pages 页数: (358 ) Write algorithms and program in the new field of quantum computing. This book covers major topics such as the physical components of a quantum computer: qubits, entanglement, logic gates, circuits, and how they differ from a traditional computer. Also, Practical Quantum Computing for Developers discusses quantum computing in the cloud using IBM Q Experience including: the composer, quantum scores, experiments, circuits, simulators, real quantum devices, and more. You’ll be able to run experiments in the cloud on a real quantum device. Furthermore, this book shows you how to do quantum programming using the QISKit (Quantum Information Software Kit), Python SDK, and other APIs such as QASM (Quantum Assembly). You’ll learn to write code using these languages and execute it against simulators (local or remote) or a real quantum computer provided by IBM’s Q Experience. Finally, you’ll learn the current quantum algorithms for entanglement, random number generation, linear search, integer factorization, and others. You’ll peak inside the inner workings of the Bell states for entanglement, Grover’s algorithm for linear search, Shor’s algorithm for integer factorization, and other algorithms in the fields of optimization, and more. Along the way you’ll also cover game theory with the Magic Square, an example of quantum pseudo-telepathy where parties sharing entangled states can be observed to have some kind of communication between them. In this game Alice and Bob play against a referee. Quantum mechanics allows Alice and Bob to always win! By the end of this book, you will understand how this emerging technology provides massive parallelism and significant computational speedups over classical computers, and wi
Computer Networking: A Top-Down Approach, 6th Edition Solutions to Review Questions and Problems Version Date: May 2012 This document contains the solutions to review questions and problems for the 5th edition of Computer Networking: A Top-Down Approach by Jim Kurose and Keith Ross. These solutions are being made available to instructors ONLY. Please do NOT copy or distribute this document to others (even other instructors). Please do not post any solutions on a publicly-available Web site. We’ll be happy to provide a copy (up-to-date) of this solution manual ourselves to anyone who asks. Acknowledgments: Over the years, several students and colleagues have helped us prepare this solutions manual. Special thanks goes to HongGang Zhang, Rakesh Kumar, Prithula Dhungel, and Vijay Annapureddy. Also thanks to all the readers who have made suggestions and corrected errors. All material © copyright 1996-2012 by J.F. Kurose and K.W. Ross. All rights reserved Chapter 1 Review Questions There is no difference. Throughout this text, the words “host” and “end system” are used interchangeably. End systems include PCs, workstations, Web servers, mail servers, PDAs, Internet-connected game consoles, etc. From Wikipedia: Diplomatic protocol is commonly described as a set of international courtesy rules. These well-established and time-honored rules have made it easier for nations and people to live and work together. Part of protocol has always been the acknowledgment of the hierarchical standing of all present. Protocol rules are based on the principles of civility. Standards are important for protocols so that people can create networking systems and products that interoperate. 1. Dial-up modem over telephone line: home; 2. DSL over telephone line: home or small office; 3. Cable to HFC: home; 4. 100 Mbps switched Ethernet: enterprise; 5. Wifi (802.11): home and enterprise: 6. 3G and 4G: wide-area wireless. HFC bandwidth is shared among the users. On the downstream channel, all packets emanate from a single source, namely, the head end. Thus, there are no collisions in the downstream channel. In most American cities, the current possibilities include: dial-up; DSL; cable modem; fiber-to-the-home. 7. Ethernet LANs have transmission rates of 10 Mbps, 100 Mbps, 1 Gbps and 10 Gbps. 8. Today, Ethernet most commonly runs over twisted-pair copper wire. It also can run over fibers optic links. 9. Dial up modems: up to 56 Kbps, bandwidth is dedicated; ADSL: up to 24 Mbps downstream and 2.5 Mbps upstream, bandwidth is dedicated; HFC, rates up to 42.8 Mbps and upstream rates of up to 30.7 Mbps, bandwidth is shared. FTTH: 2-10Mbps upload; 10-20 Mbps download; bandwidth is not shared. 10. There are two popular wireless Internet access technologies today: Wifi (802.11) In a wireless LAN, wireless users transmit/receive packets to/from an base station (i.e., wireless access point) within a radius of few tens of meters. The base station is typically connected to the wired Internet and thus serves to connect wireless users to the wired network. 3G and 4G wide-area wireless access networks. In these systems, packets are transmitted over the same wireless infrastructure used for cellular telephony, with the base station thus being managed by a telecommunications provider. This provides wireless access to users within a radius of tens of kilometers of the base station. 11. At time t0 the sending host begins to transmit. At time t1 = L/R1, the sending host completes transmission and the entire packet is received at the router (no propagation delay). Because the router has the entire packet at time t1, it can begin to transmit the packet to the receiving host at time t1. At time t2 = t1 + L/R2, the router completes transmission and the entire packet is received at the receiving host (again, no propagation delay). Thus, the end-to-end delay is L/R1 + L/R2. 12. A circuit-switched network can guarantee a certain amount of end-to-end bandwidth for the duration of a call. Most packet-switched networks today (including the Internet) cannot make any end-to-end guarantees for bandwidth. FDM requires sophisticated analog hardware to shift signal into appropriate frequency bands. 13. a) 2 users can be supported because each user requires half of the link bandwidth. b) Since each user requires 1Mbps when transmitting, if two or fewer users transmit simultaneously, a maximum of 2Mbps will be required. Since the available bandwidth of the shared link is 2Mbps, there will be no queuing delay before the link. Whereas, if three users transmit simultaneously, the bandwidth required will be 3Mbps which is more than the available bandwidth of the shared link. In this case, there will be queuing delay before the link. c) Probability that a given user is transmitting = 0.2 d) Probability that all three users are transmitting simultaneously = = (0.2)3 = 0.008. Since the queue grows when all the users are transmitting, the fraction of time during which the queue grows (which is equal to the probability that all three users are transmitting simultaneously) is 0.008. 14. If the two ISPs do not peer with each other, then when they send traffic to each other they have to send the traffic through a provider ISP (intermediary), to which they have to pay for carrying the traffic. By peering with each other directly, the two ISPs can reduce their payments to their provider ISPs. An Internet Exchange Points (IXP) (typically in a standalone building with its own switches) is a meeting point where multiple ISPs can connect and/or peer together. An ISP earns its money by charging each of the the ISPs that connect to the IXP a relatively small fee, which may depend on the amount of traffic sent to or received from the IXP. 15. Google's private network connects together all its data centers, big and small. Traffic between the Google data centers passes over its private network rather than over the public Internet. Many of these data centers are located in, or close to, lower tier ISPs. Therefore, when Google delivers content to a user, it often can bypass higher tier ISPs. What motivates content providers to create these networks? First, the content provider has more control over the user experience, since it has to use few intermediary ISPs. Second, it can save money by sending less traffic into provider networks. Third, if ISPs decide to charge more money to highly profitable content providers (in countries where net neutrality doesn't apply), the content providers can avoid these extra payments. 16. The delay components are processing delays, transmission delays, propagation delays, and queuing delays. All of these delays are fixed, except for the queuing delays, which are variable. 17. a) 1000 km, 1 Mbps, 100 bytes b) 100 km, 1 Mbps, 100 bytes 18. 10msec; d/s; no; no 19. a) 500 kbps b) 64 seconds c) 100kbps; 320 seconds 20. End system A breaks the large file into chunks. It adds header to each chunk, thereby generating multiple packets from the file. The header in each packet includes the IP address of the destination (end system B). The packet switch uses the destination IP address in the packet to determine the outgoing link. Asking which road to take is analogous to a packet asking which outgoing link it should be forwarded on, given the packet’s destination address. 21. The maximum emission rate is 500 packets/sec and the maximum transmission rate is 350 packets/sec. The corresponding traffic intensity is 500/350 =1.43 > 1. Loss will eventually occur for each experiment; but the time when loss first occurs will be different from one experiment to the next due to the randomness in the emission process. 22. Five generic tasks are error control, flow control, segmentation and reassembly, multiplexing, and connection setup. Yes, these tasks can be duplicated at different layers. For example, error control is often provided at more than one layer. 23. The five layers in the Internet protocol stack are – from top to bottom – the application layer, the transport layer, the network layer, the link layer, and the physical layer. The principal responsibilities are outlined in Section 1.5.1. 24. Application-layer message: data which an application wants to send and passed onto the transport layer; transport-layer segment: generated by the transport layer and encapsulates application-layer message with transport layer header; network-layer datagram: encapsulates transport-layer segment with a network-layer header; link-layer frame: encapsulates network-layer datagram with a link-layer header. 25. Routers process network, link and physical layers (layers 1 through 3). (This is a little bit of a white lie, as modern routers sometimes act as firewalls or caching components, and process Transport layer as well.) Link layer switches process link and physical layers (layers 1 through2). Hosts process all five layers. 26. a) Virus Requires some form of human interaction to spread. Classic example: E-mail viruses. b) Worms No user replication needed. Worm in infected host scans IP addresses and port numbers, looking for vulnerable processes to infect. 27. Creation of a botnet requires an attacker to find vulnerability in some application or system (e.g. exploiting the buffer overflow vulnerability that might exist in an application). After finding the vulnerability, the attacker needs to scan for hosts that are vulnerable. The target is basically to compromise a series of systems by exploiting that particular vulnerability. Any system that is part of the botnet can automatically scan its environment and propagate by exploiting the vulnerability. An important property of such botnets is that the originator of the botnet can remotely control and issue commands to all the nodes in the botnet. Hence, it becomes possible for the attacker to issue a command to all the nodes, that target a single node (for example, all nodes in the botnet might be commanded by the attacker to send a TCP SYN message to the target, which might result in a TCP SYN flood attack at the target). 28. Trudy can pretend to be Bob to Alice (and vice-versa) and partially or completely modify the message(s) being sent from Bob to Alice. For example, she can easily change the phrase “Alice, I owe you $1000” to “Alice, I owe you $10,000”. Furthermore, Trudy can even drop the packets that are being sent by Bob to Alice (and vise-versa), even if the packets from Bob to Alice are encrypted. Chapter 1 Problems Problem 1 There is no single right answer to this question. Many protocols would do the trick. Here's a simple answer below: Messages from ATM machine to Server Msg name purpose -------- ------- HELO Let server know that there is a card in the ATM machine ATM card transmits user ID to Server PASSWD User enters PIN, which is sent to server BALANCE User requests balance WITHDRAWL User asks to withdraw money BYE user all done Messages from Server to ATM machine (display) Msg name purpose -------- ------- PASSWD Ask user for PIN (password) OK last requested operation (PASSWD, WITHDRAWL) OK ERR last requested operation (PASSWD, WITHDRAWL) in ERROR AMOUNT sent in response to BALANCE request BYE user done, display welcome screen at ATM Correct operation: client server HELO (userid) --------------> (check if valid userid) <------------- PASSWD PASSWD --------------> (check password) <------------- AMOUNT WITHDRAWL --------------> check if enough $ to cover withdrawl (check if valid userid) <------------- PASSWD PASSWD --------------> (check password) <------------- AMOUNT WITHDRAWL --------------> check if enough $ to cover withdrawl <------------- BYE Problem 2 At time N*(L/R) the first packet has reached the destination, the second packet is stored in the last router, the third packet is stored in the next-to-last router, etc. At time N*(L/R) + L/R, the second packet has reached the destination, the third packet is stored in the last router, etc. Continuing with this logic, we see that at time N*(L/R) + (P-1)*(L/R) = (N+P-1)*(L/R) all packets have reached the destination. Problem 3 a) A circuit-switched network would be well suited to the application, because the application involves long sessions with predictable smooth bandwidth requirements. Since the transmission rate is known and not bursty, bandwidth can be reserved for each application session without significant waste. In addition, the overhead costs of setting up and tearing down connections are amortized over the lengthy duration of a typical application session. b) In the worst case, all the applications simultaneously transmit over one or more network links. However, since each link has sufficient bandwidth to handle the sum of all of the applications' data rates, no congestion (very little queuing) will occur. Given such generous link capacities, the network does not need congestion control mechanisms. Problem 4 Between the switch in the upper left and the switch in the upper right we can have 4 connections. Similarly we can have four connections between each of the 3 other pairs of adjacent switches. Thus, this network can support up to 16 connections. We can 4 connections passing through the switch in the upper-right-hand corner and another 4 connections passing through the switch in the lower-left-hand corner, giving a total of 8 connections. Yes. For the connections between A and C, we route two connections through B and two connections through D. For the connections between B and D, we route two connections through A and two connections through C. In this manner, there are at most 4 connections passing through any link. Problem 5 Tollbooths are 75 km apart, and the cars propagate at 100km/hr. A tollbooth services a car at a rate of one car every 12 seconds. a) There are ten cars. It takes 120 seconds, or 2 minutes, for the first tollbooth to service the 10 cars. Each of these cars has a propagation delay of 45 minutes (travel 75 km) before arriving at the second tollbooth. Thus, all the cars are lined up before the second tollbooth after 47 minutes. The whole process repeats itself for traveling between the second and third tollbooths. It also takes 2 minutes for the third tollbooth to service the 10 cars. Thus the total delay is 96 minutes. b) Delay between tollbooths is 8*12 seconds plus 45 minutes, i.e., 46 minutes and 36 seconds. The total delay is twice this amount plus 8*12 seconds, i.e., 94 minutes and 48 seconds. Problem 6 a) seconds. b) seconds. c) seconds. d) The bit is just leaving Host A. e) The first bit is in the link and has not reached Host B. f) The first bit has reached Host B. g) Want km. Problem 7 Consider the first bit in a packet. Before this bit can be transmitted, all of the bits in the packet must be generated. This requires sec=7msec. The time required to transmit the packet is sec= sec. Propagation delay = 10 msec. The delay until decoding is 7msec + sec + 10msec = 17.224msec A similar analysis shows that all bits experience a delay of 17.224 msec. Problem 8 a) 20 users can be supported. b) . c) . d) . We use the central limit theorem to approximate this probability. Let be independent random variables such that . “21 or more users” when is a standard normal r.v. Thus “21 or more users” . Problem 9 10,000 Problem 10 The first end system requires L/R1 to transmit the packet onto the first link; the packet propagates over the first link in d1/s1; the packet switch adds a processing delay of dproc; after receiving the entire packet, the packet switch connecting the first and the second link requires L/R2 to transmit the packet onto the second link; the packet propagates over the second link in d2/s2. Similarly, we can find the delay caused by the second switch and the third link: L/R3, dproc, and d3/s3. Adding these five delays gives dend-end = L/R1 + L/R2 + L/R3 + d1/s1 + d2/s2 + d3/s3+ dproc+ dproc To answer the second question, we simply plug the values into the equation to get 6 + 6 + 6 + 20+16 + 4 + 3 + 3 = 64 msec. Problem 11 Because bits are immediately transmitted, the packet switch does not introduce any delay; in particular, it does not introduce a transmission delay. Thus, dend-end = L/R + d1/s1 + d2/s2+ d3/s3 For the values in Problem 10, we get 6 + 20 + 16 + 4 = 46 msec. Problem 12 The arriving packet must first wait for the link to transmit 4.5 *1,500 bytes = 6,750 bytes or 54,000 bits. Since these bits are transmitted at 2 Mbps, the queuing delay is 27 msec. Generally, the queuing delay is (nL + (L - x))/R. Problem 13 The queuing delay is 0 for the first transmitted packet, L/R for the second transmitted packet, and generally, (n-1)L/R for the nth transmitted packet. Thus, the average delay for the N packets is: (L/R + 2L/R + ....... + (N-1)L/R)/N = L/(RN) * (1 + 2 + ..... + (N-1)) = L/(RN) * N(N-1)/2 = LN(N-1)/(2RN) = (N-1)L/(2R) Note that here we used the well-known fact: 1 + 2 + ....... + N = N(N+1)/2 It takes seconds to transmit the packets. Thus, the buffer is empty when a each batch of packets arrive. Thus, the average delay of a packet across all batches is the average delay within one batch, i.e., (N-1)L/2R. Problem 14 The transmission delay is . The total delay is Let . Total delay = For x=0, the total delay =0; as we increase x, total delay increases, approaching infinity as x approaches 1/a. Problem 15 Total delay . Problem 16 The total number of packets in the system includes those in the buffer and the packet that is being transmitted. So, N=10+1. Because , so (10+1)=a*(queuing delay + transmission delay). That is, 11=a*(0.01+1/100)=a*(0.01+0.01). Thus, a=550 packets/sec. Problem 17 There are nodes (the source host and the routers). Let denote the processing delay at the th node. Let be the transmission rate of the th link and let . Let be the propagation delay across the th link. Then . Let denote the average queuing delay at node . Then . Problem 18 On linux you can use the command traceroute www.targethost.com and in the Windows command prompt you can use tracert www.targethost.com In either case, you will get three delay measurements. For those three measurements you can calculate the mean and standard deviation. Repeat the experiment at different times of the day and comment on any changes. Here is an example solution: Traceroutes between San Diego Super Computer Center and www.poly.edu The average (mean) of the round-trip delays at each of the three hours is 71.18 ms, 71.38 ms and 71.55 ms, respectively. The standard deviations are 0.075 ms, 0.21 ms, 0.05 ms, respectively. In this example, the traceroutes have 12 routers in the path at each of the three hours. No, the paths didn’t change during any of the hours. Traceroute packets passed through four ISP networks from source to destination. Yes, in this experiment the largest delays occurred at peering interfaces between adjacent ISPs. Traceroutes from www.stella-net.net (France) to www.poly.edu (USA). The average round-trip delays at each of the three hours are 87.09 ms, 86.35 ms and 86.48 ms, respectively. The standard deviations are 0.53 ms, 0.18 ms, 0.23 ms, respectively. In this example, there are 11 routers in the path at each of the three hours. No, the paths didn’t change during any of the hours. Traceroute packets passed three ISP networks from source to destination. Yes, in this experiment the largest delays occurred at peering interfaces between adjacent ISPs. Problem 19 An example solution: Traceroutes from two different cities in France to New York City in United States In these traceroutes from two different cities in France to the same destination host in United States, seven links are in common including the transatlantic link. In this example of traceroutes from one city in France and from another city in Germany to the same host in United States, three links are in common including the transatlantic link. Traceroutes to two different cities in China from same host in United States Five links are common in the two traceroutes. The two traceroutes diverge before reaching China Problem 20 Throughput = min{Rs, Rc, R/M} Problem 21 If only use one path, the max throughput is given by: . If use all paths, the max throughput is given by . Problem 22 Probability of successfully receiving a packet is: ps= (1-p)N. The number of transmissions needed to be performed until the packet is successfully received by the client is a geometric random variable with success probability ps. Thus, the average number of transmissions needed is given by: 1/ps . Then, the average number of re-transmissions needed is given by: 1/ps -1. Problem 23 Let’s call the first packet A and call the second packet B. If the bottleneck link is the first link, then packet B is queued at the first link waiting for the transmission of packet A. So the packet inter-arrival time at the destination is simply L/Rs. If the second link is the bottleneck link and both packets are sent back to back, it must be true that the second packet arrives at the input queue of the second link before the second link finishes the transmission of the first packet. That is, L/Rs + L/Rs + dprop = L/Rs + dprop + L/Rc Thus, the minimum value of T is L/Rc  L/Rs . Problem 24 40 terabytes = 40 * 1012 * 8 bits. So, if using the dedicated link, it will take 40 * 1012 * 8 / (100 *106 ) =3200000 seconds = 37 days. But with FedEx overnight delivery, you can guarantee the data arrives in one day, and it should cost less than $100. Problem 25 160,000 bits 160,000 bits The bandwidth-delay product of a link is the maximum number of bits that can be in the link. the width of a bit = length of link / bandwidth-delay product, so 1 bit is 125 meters long, which is longer than a football field s/R Problem 26 s/R=20000km, then R=s/20000km= 2.5*108/(2*107)= 12.5 bps Problem 27 80,000,000 bits 800,000 bits, this is because that the maximum number of bits that will be in the link at any given time = min(bandwidth delay product, packet size) = 800,000 bits. .25 meters Problem 28 ttrans + tprop = 400 msec + 80 msec = 480 msec. 20 * (ttrans + 2 tprop) = 20*(20 msec + 80 msec) = 2 sec. Breaking up a file takes longer to transmit because each data packet and its corresponding acknowledgement packet add their own propagation delays. Problem 29 Recall geostationary satellite is 36,000 kilometers away from earth surface. 150 msec 1,500,000 bits 600,000,000 bits Problem 30 Let’s suppose the passenger and his/her bags correspond to the data unit arriving to the top of the protocol stack. When the passenger checks in, his/her bags are checked, and a tag is attached to the bags and ticket. This is additional information added in the Baggage layer if Figure 1.20 that allows the Baggage layer to implement the service or separating the passengers and baggage on the sending side, and then reuniting them (hopefully!) on the destination side. When a passenger then passes through security and additional stamp is often added to his/her ticket, indicating that the passenger has passed through a security check. This information is used to ensure (e.g., by later checks for the security information) secure transfer of people. Problem 31 Time to send message from source host to first packet switch = With store-and-forward switching, the total time to move message from source host to destination host = Time to send 1st packet from source host to first packet switch = . . Time at which 2nd packet is received at the first switch = time at which 1st packet is received at the second switch = Time at which 1st packet is received at the destination host = . After this, every 5msec one packet will be received; thus time at which last (800th) packet is received = . It can be seen that delay in using message segmentation is significantly less (almost 1/3rd). Without message segmentation, if bit errors are not tolerated, if there is a single bit error, the whole message has to be retransmitted (rather than a single packet). Without message segmentation, huge packets (containing HD videos, for example) are sent into the network. Routers have to accommodate these huge packets. Smaller packets have to queue behind enormous packets and suffer unfair delays. Packets have to be put in sequence at the destination. Message segmentation results in many smaller packets. Since header size is usually the same for all packets regardless of their size, with message segmentation the total amount of header bytes is more. Problem 32 Yes, the delays in the applet correspond to the delays in the Problem 31.The propagation delays affect the overall end-to-end delays both for packet switching and message switching equally. Problem 33 There are F/S packets. Each packet is S=80 bits. Time at which the last packet is received at the first router is sec. At this time, the first F/S-2 packets are at the destination, and the F/S-1 packet is at the second router. The last packet must then be transmitted by the first router and the second router, with each transmission taking sec. Thus delay in sending the whole file is To calculate the value of S which leads to the minimum delay, Problem 34 The circuit-switched telephone networks and the Internet are connected together at "gateways". When a Skype user (connected to the Internet) calls an ordinary telephone, a circuit is established between a gateway and the telephone user over the circuit switched network. The skype user's voice is sent in packets over the Internet to the gateway. At the gateway, the voice signal is reconstructed and then sent over the circuit. In the other direction, the voice signal is sent over the circuit switched network to the gateway. The gateway packetizes the voice signal and sends the voice packets to the Skype user.   Chapter 2 Review Questions The Web: HTTP; file transfer: FTP; remote login: Telnet; e-mail: SMTP; BitTorrent file sharing: BitTorrent protocol Network architecture refers to the organization of the communication process into layers (e.g., the five-layer Internet architecture). Application architecture, on the other hand, is designed by an application developer and dictates the broad structure of the application (e.g., client-server or P2P). The process which initiates the communication is the client; the process that waits to be contacted is the server. No. In a P2P file-sharing application, the peer that is receiving a file is typically the client and the peer that is sending the file is typically the server. The IP address of the destination host and the port number of the socket in the destination process. You would use UDP. With UDP, the transaction can be completed in one roundtrip time (RTT) - the client sends the transaction request into a UDP socket, and the server sends the reply back to the client's UDP socket. With TCP, a minimum of two RTTs are needed - one to set-up the TCP connection, and another for the client to send the request, and for the server to send back the reply. One such example is remote word processing, for example, with Google docs. However, because Google docs runs over the Internet (using TCP), timing guarantees are not provided. a) Reliable data transfer TCP provides a reliable byte-stream between client and server but UDP does not. b) A guarantee that a certain value for throughput will be maintained Neither c) A guarantee that data will be delivered within a specified amount of time Neither d) Confidentiality (via encryption) Neither SSL operates at the application layer. The SSL socket takes unencrypted data from the application layer, encrypts it and then passes it to the TCP socket. If the application developer wants TCP to be enhanced with SSL, she has to include the SSL code in the application. A protocol uses handshaking if the two communicating entities first exchange control packets before sending data to each other. SMTP uses handshaking at the application layer whereas HTTP does not. The applications associated with those protocols require that all application data be received in the correct order and without gaps. TCP provides this service whereas UDP does not. When the user first visits the site, the server creates a unique identification number, creates an entry in its back-end database, and returns this identification number as a cookie number. This cookie number is stored on the user’s host and is managed by the browser. During each subsequent visit (and purchase), the browser sends the cookie number back to the site. Thus the site knows when this user (more precisely, this browser) is visiting the site. Web caching can bring the desired content “closer” to the user, possibly to the same LAN to which the user’s host is connected. Web caching can reduce the delay for all objects, even objects that are not cached, since caching reduces the traffic on links. Telnet is not available in Windows 7 by default. to make it available, go to Control Panel, Programs and Features, Turn Windows Features On or Off, Check Telnet client. To start Telnet, in Windows command prompt, issue the following command > telnet webserverver 80 where "webserver" is some webserver. After issuing the command, you have established a TCP connection between your client telnet program and the web server. Then type in an HTTP GET message. An example is given below: Since the index.html page in this web server was not modified since Fri, 18 May 2007 09:23:34 GMT, and the above commands were issued on Sat, 19 May 2007, the server returned "304 Not Modified". Note that the first 4 lines are the GET message and header lines inputed by the user, and the next 4 lines (starting from HTTP/1.1 304 Not Modified) is the response from the web server. FTP uses two parallel TCP connections, one connection for sending control information (such as a request to transfer a file) and another connection for actually transferring the file. Because the control information is not sent over the same connection that the file is sent over, FTP sends control information out of band. The message is first sent from Alice’s host to her mail server over HTTP. Alice’s mail server then sends the message to Bob’s mail server over SMTP. Bob then transfers the message from his mail server to his host over POP3. 17. Received: from 65.54.246.203 (EHLO bay0-omc3-s3.bay0.hotmail.com) (65.54.246.203) by mta419.mail.mud.yahoo.com with SMTP; Sat, 19 May 2007 16:53:51 -0700 Received: from hotmail.com ([65.55.135.106]) by bay0-omc3-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 19 May 2007 16:52:42 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 19 May 2007 16:52:41 -0700 Message-ID: Received: from 65.55.135.123 by by130fd.bay130.hotmail.msn.com with HTTP; Sat, 19 May 2007 23:52:36 GMT From: "prithula dhungel" To: prithula@yahoo.com Bcc: Subject: Test mail Date: Sat, 19 May 2007 23:52:36 +0000 Mime-Version: 1.0 Content-Type: Text/html; format=flowed Return-Path: prithuladhungel@hotmail.com Figure: A sample mail message header Received: This header field indicates the sequence in which the SMTP servers send and receive the mail message including the respective timestamps. In this example there are 4 “Received:” header lines. This means the mail message passed through 5 different SMTP servers before being delivered to the receiver’s mail box. The last (forth) “Received:” header indicates the mail message flow from the SMTP server of the sender to the second SMTP server in the chain of servers. The sender’s SMTP server is at address 65.55.135.123 and the second SMTP server in the chain is by130fd.bay130.hotmail.msn.com. The third “Received:” header indicates the mail message flow from the second SMTP server in the chain to the third server, and so on. Finally, the first “Received:” header indicates the flow of the mail messages from the forth SMTP server to the last SMTP server (i.e. the receiver’s mail server) in the chain. Message-id: The message has been given this number BAY130-F26D9E35BF59E0D18A819AFB9310@phx.gbl (by bay0-omc3-s3.bay0.hotmail.com. Message-id is a unique string assigned by the mail system when the message is first created. From: This indicates the email address of the sender of the mail. In the given example, the sender is “prithuladhungel@hotmail.com” To: This field indicates the email address of the receiver of the mail. In the example, the receiver is “prithula@yahoo.com” Subject: This gives the subject of the mail (if any specified by the sender). In the example, the subject specified by the sender is “Test mail” Date: The date and time when the mail was sent by the sender. In the example, the sender sent the mail on 19th May 2007, at time 23:52:36 GMT. Mime-version: MIME version used for the mail. In the example, it is 1.0. Content-type: The type of content in the body of the mail message. In the example, it is “text/html”. Return-Path: This specifies the email address to which the mail will be sent if the receiver of this mail wants to reply to the sender. This is also used by the sender’s mail server for bouncing back undeliverable mail messages of mailer-daemon error messages. In the example, the return path is “prithuladhungel@hotmail.com”. With download and delete, after a user retrieves its messages from a POP server, the messages are deleted. This poses a problem for the nomadic user, who may want to access the messages from many different machines (office PC, home PC, etc.). In the download and keep configuration, messages are not deleted after the user retrieves the messages. This can also be inconvenient, as each time the user retrieves the stored messages from a new machine, all of non-deleted messages will be transferred to the new machine (including very old messages). Yes an organization’s mail server and Web server can have the same alias for a host name. The MX record is used to map the mail server’s host name to its IP address. You should be able to see the sender's IP address for a user with an .edu email address. But you will not be able to see the sender's IP address if the user uses a gmail account. It is not necessary that Bob will also provide chunks to Alice. Alice has to be in the top 4 neighbors of Bob for Bob to send out chunks to her; this might not occur even if Alice provides chunks to Bob throughout a 30-second interval. Recall that in BitTorrent, a peer picks a random peer and optimistically unchokes the peer for a short period of time. Therefore, Alice will eventually be optimistically unchoked by one of her neighbors, during which time she will receive chunks from that neighbor. The overlay network in a P2P file sharing system consists of the nodes participating in the file sharing system and the logical links between the nodes. There is a logical link (an “edge” in graph theory terms) from node A to node B if there is a semi-permanent TCP connection between A and B. An overlay network does not include routers. Mesh DHT: The advantage is in order to a route a message to the peer (with ID) that is closest to the key, only one hop is required; the disadvantage is that each peer must track all other peers in the DHT. Circular DHT: the advantage is that each peer needs to track only a few other peers; the disadvantage is that O(N) hops are needed to route a message to the peer that is closest to the key. 25. File Distribution Instant Messaging Video Streaming Distributed Computing With the UDP server, there is no welcoming socket, and all data from different clients enters the server through this one socket. With the TCP server, there is a welcoming socket, and each time a client initiates a connection to the server, a new socket is created. Thus, to support n simultaneous connections, the server would need n+1 sockets. For the TCP application, as soon as the client is executed, it attempts to initiate a TCP connection with the server. If the TCP server is not running, then the client will fail to make a connection. For the UDP application, the client does not initiate connections (or attempt to communicate with the UDP server) immediately upon execution Chapter 2 Problems Problem 1 a) F b) T c) F d) F e) F Problem 2 Access control commands: USER, PASS, ACT, CWD, CDUP, SMNT, REIN, QUIT. Transfer parameter commands: PORT, PASV, TYPE STRU, MODE. Service commands: RETR, STOR, STOU, APPE, ALLO, REST, RNFR, RNTO, ABOR, DELE, RMD, MRD, PWD, LIST, NLST, SITE, SYST, STAT, HELP, NOOP. Problem 3 Application layer protocols: DNS and HTTP Transport layer protocols: UDP for DNS; TCP for HTTP Problem 4 The document request was http://gaia.cs.umass.edu/cs453/index.html. The Host : field indicates the server's name and /cs453/index.html indicates the file name. The browser is running HTTP version 1.1, as indicated just before the first pair. The browser is requesting a persistent connection, as indicated by the Connection: keep-alive. This is a trick question. This information is not contained in an HTTP message anywhere. So there is no way to tell this from looking at the exchange of HTTP messages alone. One would need information from the IP datagrams (that carried the TCP segment that carried the HTTP GET request) to answer this question. Mozilla/5.0. The browser type information is needed by the server to send different versions of the same object to different types of browsers. Problem 5 The status code of 200 and the phrase OK indicate that the server was able to locate the document successfully. The reply was provided on Tuesday, 07 Mar 2008 12:39:45 Greenwich Mean Time. The document index.html was last modified on Saturday 10 Dec 2005 18:27:46 GMT. There are 3874 bytes in the document being returned. The first five bytes of the returned document are : finding cnn.com. If cnn.com was just accessed a couple of seconds ago, an entry for cnn.com is cached in the local DNS cache, so the query time is 0 msec. Otherwise, the query time is large. Problem 22 For calculating the minimum distribution time for client-server distribution, we use the following formula: Dcs = max {NF/us, F/dmin} Similarly, for calculating the minimum distribution time for P2P distribution, we use the following formula: Where, F = 15 Gbits = 15 * 1024 Mbits us = 30 Mbps dmin = di = 2 Mbps Note, 300Kbps = 300/1024 Mbps. Client Server N 10 100 1000 u 300 Kbps 7680 51200 512000 700 Kbps 7680 51200 512000 2 Mbps 7680 51200 512000 Peer to Peer N 10 100 1000 u 300 Kbps 7680 25904 47559 700 Kbps 7680 15616 21525 2 Mbps 7680 7680 7680 Problem 23 Consider a distribution scheme in which the server sends the file to each client, in parallel, at a rate of a rate of us/N. Note that this rate is less than each of the client’s download rate, since by assumption us/N ≤ dmin. Thus each client can also receive at rate us/N. Since each client receives at rate us/N, the time for each client to receive the entire file is F/( us/N) = NF/ us. Since all the clients receive the file in NF/ us, the overall distribution time is also NF/ us. Consider a distribution scheme in which the server sends the file to each client, in parallel, at a rate of dmin. Note that the aggregate rate, N dmin, is less than the server’s link rate us, since by assumption us/N ≥ dmin. Since each client receives at rate dmin, the time for each client to receive the entire file is F/ dmin. Since all the clients receive the file in this time, the overall distribution time is also F/ dmin. From Section 2.6 we know that DCS ≥ max {NF/us, F/dmin} (Equation 1) Suppose that us/N ≤ dmin. Then from Equation 1 we have DCS ≥ NF/us . But from (a) we have DCS ≤ NF/us . Combining these two gives: DCS = NF/us when us/N ≤ dmin. (Equation 2) We can similarly show that: DCS =F/dmin when us/N ≥ dmin (Equation 3). Combining Equation 2 and Equation 3 gives the desired result. Problem 24 Define u = u1 + u2 + ….. + uN. By assumption us <= (us + u)/N Equation 1 Divide the file into N parts, with the ith part having size (ui/u)F. The server transmits the ith part to peer i at rate ri = (ui/u)us. Note that r1 + r2 + ….. + rN = us, so that the aggregate server rate does not exceed the link rate of the server. Also have each peer i forward the bits it receives to each of the N-1 peers at rate ri. The aggregate forwarding rate by peer i is (N-1)ri. We have (N-1)ri = (N-1)(usui)/u = (us + u)/N Equation 2 Let ri = ui/(N-1) and rN+1 = (us – u/(N-1))/N In this distribution scheme, the file is broken into N+1 parts. The server sends bits from the ith part to the ith peer (i = 1, …., N) at rate ri. Each peer i forwards the bits arriving at rate ri to each of the other N-1 peers. Additionally, the server sends bits from the (N+1) st part at rate rN+1 to each of the N peers. The peers do not forward the bits from the (N+1)st part. The aggregate send rate of the server is r1+ …. + rN + N rN+1 = u/(N-1) + us – u/(N-1) = us Thus, the server’s send rate does not exceed its link rate. The aggregate send rate of peer i is (N-1)ri = ui Thus, each peer’s send rate does not exceed its link rate. In this distribution scheme, peer i receives bits at an aggregate rate of Thus each peer receives the file in NF/(us+u). (For simplicity, we neglected to specify the size of the file part for i = 1, …., N+1. We now provide that here. Let Δ = (us+u)/N be the distribution time. For i = 1, …, N, the ith file part is Fi = ri Δ bits. The (N+1)st file part is FN+1 = rN+1 Δ bits. It is straightforward to show that F1+ ….. + FN+1 = F.) The solution to this part is similar to that of 17 (c). We know from section 2.6 that Combining this with a) and b) gives the desired result. Problem 25 There are N nodes in the overlay network. There are N(N-1)/2 edges. Problem 26 Yes. His first claim is possible, as long as there are enough peers staying in the swarm for a long enough time. Bob can always receive data through optimistic unchoking by other peers. His second claim is also true. He can run a client on each host, let each client “free-ride,” and combine the collected chunks from the different hosts into a single file. He can even write a small scheduling program to make the different hosts ask for different chunks of the file. This is actually a kind of Sybil attack in P2P networks. Problem 27 Peer 3 learns that peer 5 has just left the system, so Peer 3 asks its first successor (Peer 4) for the identifier of its immediate successor (peer 8). Peer 3 will then make peer 8 its second successor. Problem 28 Peer 6 would first send peer 15 a message, saying “what will be peer 6’s predecessor and successor?” This message gets forwarded through the DHT until it reaches peer 5, who realizes that it will be 6’s predecessor and that its current successor, peer 8, will become 6’s successor. Next, peer 5 sends this predecessor and successor information back to 6. Peer 6 can now join the DHT by making peer 8 its successor and by notifying peer 5 that it should change its immediate successor to 6. Problem 29 For each key, we first calculate the distances (using d(k,p)) between itself and all peers, and then store the key in the peer that is closest to the key (that is, with smallest distance value). Problem 30 Yes, randomly assigning keys to peers does not consider the underlying network at all, so it very likely causes mismatches. Such mismatches may degrade the search performance. For example, consider a logical path p1 (consisting of only two logical links): ABC, where A and B are neighboring peers, and B and C are neighboring peers. Suppose that there is another logical path p2 from A to C (consisting of 3 logical links): ADEC. It might be the case that A and B are very far away physically (and separated by many routers), and B and C are very far away physically (and separated by many routers). But it may be the case that A, D, E, and C are all very close physically (and all separated by few routers). In other words, a shorter logical path may correspond to a much longer physical path. Problem 31 If you run TCPClient first, then the client will attempt to make a TCP connection with a non-existent server process. A TCP connection will not be made. UDPClient doesn't establish a TCP connection with the server. Thus, everything should work fine if you first run UDPClient, then run UDPServer, and then type some input into the keyboard. If you use different port numbers, then the client will attempt to establish a TCP connection with the wrong process or a non-existent process. Errors will occur. Problem 32 In the original program, UDPClient does not specify a port number when it creates the socket. In this case, the code lets the underlying operating system choose a port number. With the additional line, when UDPClient is executed, a UDP socket is created with port number 5432 . UDPServer needs to know the client port number so that it can send packets back to the correct client socket. Glancing at UDPServer, we see that the client port number is not “hard-wired” into the server code; instead, UDPServer determines the client port number by unraveling the datagram it receives from the client. Thus UDP server will work with any client port number, including 5432. UDPServer therefore does not need to be modified. Before: Client socket = x (chosen by OS) Server socket = 9876 After: Client socket = 5432 Problem 33 Yes, you can configure many browsers to open multiple simultaneous connections to a Web site. The advantage is that you will you potentially download the file faster. The disadvantage is that you may be hogging the bandwidth, thereby significantly slowing down the downloads of other users who are sharing the same physical links. Problem 34 For an application such as remote login (telnet and ssh), a byte-stream oriented protocol is very natural since there is no notion of message boundaries in the application. When a user types a character, we simply drop the character into the TCP connection. In other applications, we may be sending a series of messages that have inherent boundaries between them. For example, when one SMTP mail server sends another SMTP mail server several email messages back to back. Since TCP does not have a mechanism to indicate the boundaries, the application must add the indications itself, so that receiving side of the application can distinguish one message from the next. If each message were instead put into a distinct UDP segment, the receiving end would be able to distinguish the various messages without any indications added by the sending side of the application. Problem 35 To create a web server, we need to run web server software on a host. Many vendors sell web server software. However, the most popular web server software today is Apache, which is open source and free. Over the years it has been highly optimized by the open-source community. Problem 36 The key is the infohash, the value is an IP address that currently has the file designated by the infohash.   Chapter 3 Review Questions Call this protocol Simple Transport Protocol (STP). At the sender side, STP accepts from the sending process a chunk of data not exceeding 1196 bytes, a destination host address, and a destination port number. STP adds a four-byte header to each chunk and puts the port number of the destination process in this header. STP then gives the destination host address and the resulting segment to the network layer. The network layer delivers the segment to STP at the destination host. STP then examines the port number in the segment, extracts the data from the segment, and passes the data to the process identified by the port number. The segment now has two header fields: a source port field and destination port field. At the sender side, STP accepts a chunk of data not exceeding 1192 bytes, a destination host address, a source port number, and a destination port number. STP creates a segment which contains the application data, source port number, and destination port number. It then gives the segment and the destination host address to the network layer. After receiving the segment, STP at the receiving host gives the application process the application data and the source port number. No, the transport layer does not have to do anything in the core; the transport layer “lives” in the end systems. For sending a letter, the family member is required to give the delegate the letter itself, the address of the destination house, and the name of the recipient. The delegate clearly writes the recipient’s name on the top of the letter. The delegate then puts the letter in an envelope and writes the address of the destination house on the envelope. The delegate then gives the letter to the planet’s mail service. At the receiving side, the delegate receives the letter from the mail service, takes the letter out of the envelope, and takes note of the recipient name written at the top of the letter. The delegate then gives the letter to the family member with this name. No, the mail service does not have to open the envelope; it only examines the address on the envelope. Source port number y and destination port number x. An application developer may not want its application to use TCP’s congestion control, which can throttle the application’s sending rate at times of congestion. Often, designers of IP telephony and IP videoconference applications choose to run their applications over UDP because they want to avoid TCP’s congestion control. Also, some applications do not need the reliable data transfer provided by TCP. Since most firewalls are configured to block UDP traffic, using TCP for video and voice traffic lets the traffic though the firewalls. Yes. The application developer can put reliable data transfer into the application layer protocol. This would require a significant amount of work and debugging, however. Yes, both segments will be directed to the same socket. For each received segment, at the socket interface, the operating system will provide the process with the IP addresses to determine the origins of the individual segments. For each persistent connection, the Web server creates a separate “connection socket”. Each connection socket is identified with a four-tuple: (source IP address, source port number, destination IP address, destination port number). When host C receives and IP datagram, it examines these four fields in the datagram/segment to determine to which socket it should pass the payload of the TCP segment. Thus, the requests from A and B pass through different sockets. The identifier for both of these sockets has 80 for the destination port; however, the identifiers for these sockets have different values for source IP addresses. Unlike UDP, when the transport layer passes a TCP segment’s payload to the application process, it does not specify the source IP address, as this is implicitly specified by the socket identifier. Sequence numbers are required for a receiver to find out whether an arriving packet contains new data or is a retransmission. To handle losses in the channel. If the ACK for a transmitted packet is not received within the duration of the timer for the packet, the packet (or its ACK or NACK) is assumed to have been lost. Hence, the packet is retransmitted. A timer would still be necessary in the protocol rdt 3.0. If the round trip time is known then the only advantage will be that, the sender knows for sure that either the packet or the ACK (or NACK) for the packet has been lost, as compared to the real scenario, where the ACK (or NACK) might still be on the way to the sender, after the timer expires. However, to detect the loss, for each packet, a timer of constant duration will still be necessary at the sender. The packet loss caused a time out after which all the five packets were retransmitted. Loss of an ACK didn’t trigger any retransmission as Go-Back-N uses cumulative acknowledgements. The sender was unable to send sixth packet as the send window size is fixed to 5. When the packet was lost, the received four packets were buffered the receiver. After the timeout, sender retransmitted the lost packet and receiver delivered the buffered packets to application in correct order. Duplicate ACK was sent by the receiver for the lost ACK. The sender was unable to send sixth packet as the send win
Android, the next-generation open mobile platform from Google and the Open Handset Alliance, is poised to become a significant player in the mobile device market. The Android platform gives developers a fair bit of control while still supporting a familiar programming language. However, the frameworks, GUI widgets, and development model is different than any other mobile platform out there. That’s where this book comes in Spanning 466 pages, The Busy Coder’s Guide to Android Development covers a wide range of Android capabilities and APIs, from creating simple user interfaces, to supporting long-running background processes, through the advanced location tracking and mapping features. Along the way, it covers how to embed the WebKit Web browser in your application, how to have your application use data from other installed applications (and vice versa!) or off the Internet, and how to integrate with the built-in on-device search engine. It will help you more quickly climb the Android learning curve, so you can create the “killer app” you’ve dreamed of…or perhaps just a quick-and-dirty application for you and your friends. Table of Contents Preface Key Android Concepts Choosing Your Development Toolchain Tutorial #1 - Installing the Tools Android and Projects Tutorial #2 - Creating a Stub Project Getting Around Android Studio Contents of Android Projects Introducing Gradle and the Manifest Tutorial #3 - Changing Our Manifest (and Gradle File) Some Words About Resources Tutorial #4 - Adjusting Our Resources The Theory of Widgets The Android User Interface Basic Widgets Debugging Your App LinearLayout and the Box Model Other Common Widgets and Containers Tutorial #5 - Making Progress GUI Building, Continued AdapterViews and Adapters The WebView Widget Defining and Using Styles JARs and Library Projects Tutorial #6 - Adding a Library The Action Bar Tutorial #7 - Setting Up the Action Bar Android’s Process Model Activities and Their Lifecycles Tutorial #8 - Setting Up An Activity The Tactics of Fragments Tutorial #9 - Starting Our Fragments Swiping with ViewPager Tutorial #10 - Rigging Up a ViewPager Resource Sets and Configurations Material Design Basics Dealing with Threads Requesting Permissions Tutorial: Runtime Permission Support Assets, Files, and Data Parsing Tutorial #11 - Adding Simple Content Tutorial #12 - Displaying the Book Using Preferences Tutorial #13 - Using Some Preferences SQLite Databases Tutorial #14 - Saving Notes Internet Access Intents, Intent Filters Broadcasts and Broadcast Receivers Tutorial #15 - Sharing Your Notes Services and the Command Pattern Tutorial #16 - Updating the Book Large-Screen Strategies and Tactics Tutorial #17 - Supporting Large Screens Backwards Compatibility Strategies and Tactics System Services Google Play Services Getting Help Working with Library Projects Gradle and Legacy Projects Gradle and Tasks Gradle and the New Project Structure Gradle and Dependencies Manifest Merger Rules Signing Your App Distribution Advanced Gradle for Android Tips Testing with JUnit4 Testing with UI Automator Measuring Test Coverage Unit Testing MonkeyRunner and the Test Monkey Notifications Advanced Notifications Introducing GridLayout The Percent Support Library Dialogs and DialogFragments Advanced ListViews Action Bar Navigation Action Modes Other Advanced Action Bar Techniques Toolbar AppCompat: The Official Action Bar Backport RecyclerView Implementing a Navigation Drawer The Android Design Support Library Advanced Uses of WebView The Input Method Framework Fonts Rich Text Animators Legacy Animations Custom Drawables Mapping with Maps V2 Crafting Your Own Views Advanced Preferences Custom Dialogs and Preferences Progress Indicators More Fun with Pagers Focus Management and Accessibility Miscellaneous UI Tricks Event Bus Alternatives Tasks The Assist API (“Now On Tap”) The Data Binding Framework Desktop Android Apps Drag and Drop Keyboard and Mouse Input Home Screen App Widgets Adapter-Based App Widgets Content Provider Theory Content Provider Implementation Patterns The Loader Framework The ContactsContract and CallLog Providers The CalendarContract Provider The MediaStore Provider Consuming Documents Providing Documents Encrypted Storage Packaging and Distributing Data Advanced Database Techniques Data Backup SSL NetCipher Embedding a Web Server Miscellaneous Network Capabilities Audio Playback Audio Recording Video Playback Using the Camera via 3rd-Party Apps Working Directly with the Camera Media Routes Supporting External Displays Google Cast and Chromecast The “Ten-Foot UI” Putting the TVs All Together: Decktastic Creating a MediaRouteProvider Screenshots and Screen Recordings Advanced Permissions Restricted Profiles and UserManager Miscellaneous Security Techniques AlarmManager and the Scheduled Service Pattern PowerManager and WakeLocks JobScheduler Accessing Location-Based Services The Fused Location Provider Working with the Clipboard Telephony Working With SMS NFC Device Administration Basic Use of Sensors Printing and Document Generation Dealing with Different Hardware Writing and Using Parcelables Responding to URLs Plugin Patterns PackageManager Tricks Remote Services and the Binding Pattern Advanced Manifest Tips Miscellaneous Integration Tips Reusable Components Android Studio Editors and Dialogs Advanced Emulator Capabilities Lint and the Support Annotations Using Hierarchy View Screenshots and Screencasts ADB Tips and Tricks Issues with Speed Finding CPU Bottlenecks Focus On: NDK Improving CPU Performance in Java Finding and Eliminating Jank Issues with Bandwidth Focus On: TrafficStats Measuring Bandwidth Consumption Being Smarter About Bandwidth Issues with Application Heap Finding Memory Leaks Issues with System RAM Issues with Battery Life Power Measurement Options Sources of Power Drain Addressing Application Size Issues The Role of Scripting Languages The Scripting Layer for Android JVM Scripting Languages Crash Reporting Using ACRA In-App Diagnostics Anti-Patterns Widget Catalog: AdapterViewFlipper Widget Catalog: CalendarView Widget Catalog: DatePicker Widget Catalog: ExpandableListView Widget Catalog: SeekBar Widget Catalog: SlidingDrawer Widget Catalog: StackView Widget Catalog: TabHost and TabWidget Widget Catalog: TimePicker Widget Catalog: ViewFlipper Chrome and Chrome OS Device Catalog: Kindle Fire Device Catalog: BlackBerry Device Catalog: Android TV Device Catalog: Amazon Fire TV and Fire TV Stick Appendix A: CWAC Libraries Appendix B: N Developer Preview Appendix C: Community Theater and the Appinars Title: The Busy Coder’s Guide to Android Development Author: Mark L. Murphy Length: 3893 pages Edition: Revised & enlarged Language: English Publisher: CommonsWare Publication Date: 2016-06-06 ISBN-10: 0981678009 ISBN-13: 9780981678009
I. Spring Boot Documentation 1. About the Documentation 2. Getting Help 3. First Steps 4. Working with Spring Boot 5. Learning about Spring Boot Features 6. Moving to Production 7. Advanced Topics II. Getting Started 8. Introducing Spring Boot 9. System Requirements 9.1. Servlet Containers 10. Installing Spring Boot 10.1. Installation Instructions for the Java Developer 10.1.1. Maven Installation 10.1.2. Gradle Installation 10.2. Installing the Spring Boot CLI 10.2.1. Manual Installation 10.2.2. Installation with SDKMAN! 10.2.3. OSX Homebrew Installation 10.2.4. MacPorts Installation 10.2.5. Command-line Completion 10.2.6. Quick-start Spring CLI Example 10.3. Upgrading from an Earlier Version of Spring Boot 11. Developing Your First Spring Boot Application 11.1. Creating the POM 11.2. Adding Classpath Dependencies 11.3. Writing the Code 11.3.1. The @RestController and @RequestMapping Annotations 11.3.2. The @EnableAutoConfiguration Annotation 11.3.3. The “main” Method 11.4. Running the Example 11.5. Creating an Executable Jar 12. What to Read Next III. Using Spring Boot 13. Build Systems 13.1. Dependency Management 13.2. Maven 13.2.1. Inheriting the Starter Parent 13.2.2. Using Spring Boot without the Parent POM 13.2.3. Using the Spring Boot Maven Plugin 13.3. Gradle 13.4. Ant 13.5. Starters 14. Structuring Your Code 14.1. Using the “default” Package 14.2. Locating the Main Application Class 15. Configuration Classes 15.1. Importing Additional Configuration Classes 15.2. Importing XML Configuration 16. Auto-configuration 16.1. Gradually Replacing Auto-configuration 16.2. Disabling Specific Auto-configuration Classes 17. Spring Beans and Dependency Injection 18. Using the @SpringBootApplication Annotation 19. Running Your Application 19.1. Running from an IDE 19.2. Running as a Packaged Application 19.3. Using the Maven Plugin 19.4. Using the Gradle Plugin 19.5. Hot Swapping 20. Developer Tools 20.1. Property Defaults 20.2. Automatic Restart 20.2.1. Logging changes in condition evaluation 20.2.2. Excluding Resources 20.2.3. Watching Additional Paths 20.2.4. Disabling Restart 20.2.5. Using a Trigger File 20.2.6. Customizing the Restart Classloader 20.2.7. Known Limitations 20.3. LiveReload 20.4. Global Settings 20.5. Remote Applications 20.5.1. Running the Remote Client Application 20.5.2. Remote Update 21. Packaging Your Application for Production 22. What to Read Next IV. Spring Boot features 23. SpringApplication 23.1. Startup Failure 23.2. Customizing the Banner 23.3. Customizing SpringApplication 23.4. Fluent Builder API 23.5. Application Events and Listeners 23.6. Web Environment 23.7. Accessing Application Arguments 23.8. Using the ApplicationRunner or CommandLineRunner 23.9. Application Exit 23.10. Admin Features 24. Externalized Configuration 24.1. Configuring Random Values 24.2. Accessing Command Line Properties 24.3. Application Property Files 24.4. Profile-specific Properties 24.5. Placeholders in Properties 24.6. Using YAML Instead of Properties 24.6.1. Loading YAML 24.6.2. Exposing YAML as Properties in the Spring Environment 24.6.3. Multi-profile YAML Documents 24.6.4. YAML Shortcomings 24.7. Type-safe Configuration Properties 24.7.1. Third-party Configuration 24.7.2. Relaxed Binding 24.7.3. Merging Complex Types 24.7.4. Properties Conversion Converting durations 24.7.5. @ConfigurationProperties Validation 24.7.6. @ConfigurationProperties vs. @Value 25. Profiles 25.1. Adding Active Profiles 25.2. Programmatically Setting Profiles 25.3. Profile-specific Configuration Files 26. Logging 26.1. Log Format 26.2. Console Output 26.2.1. Color-coded Output 26.3. File Output 26.4. Log Levels 26.5. Custom Log Configuration 26.6. Logback Extensions 26.6.1. Profile-specific Configuration 26.6.2. Environment Properties 27. Developing Web Applications 27.1. The “Spring Web MVC Framework” 27.1.1. Spring MVC Auto-configuration 27.1.2. HttpMessageConverters 27.1.3. Custom JSON Serializers and Deserializers 27.1.4. MessageCodesResolver 27.1.5. Static Content 27.1.6. Welcome Page 27.1.7. Custom Favicon 27.1.8. Path Matching and Content Negotiation 27.1.9. ConfigurableWebBindingInitializer 27.1.10. Template Engines 27.1.11. Error Handling Custom Error Pages Mapping Error Pages outside of Spring MVC 27.1.12. Spring HATEOAS 27.1.13. CORS Support 27.2. The “Spring WebFlux Framework” 27.2.1. Spring WebFlux Auto-configuration 27.2.2. HTTP Codecs with HttpMessageReaders and HttpMessageWriters 27.2.3. Static Content 27.2.4. Template Engines 27.2.5. Error Handling Custom Error Pages 27.2.6. Web Filters 27.3. JAX-RS and Jersey 27.4. Embedded Servlet Container Support 27.4.1. Servlets, Filters, and listeners Registering Servlets, Filters, and Listeners as Spring Beans 27.4.2. Servlet Context Initialization Scanning for Servlets, Filters, and listeners 27.4.3. The ServletWebServerApplicationContext 27.4.4. Customizing Embedded Servlet Containers Programmatic Customization Customizing ConfigurableServletWebServerFactory Directly 27.4.5. JSP Limitations 28. Security 28.1. MVC Security 28.2. WebFlux Security 28.3. OAuth2 28.3.1. Client 28.3.2. Server 28.4. Actuator Security 28.4.1. Cross Site Request Forgery Protection 29. Working with SQL Databases 29.1. Configure a DataSource 29.1.1. Embedded Database Support 29.1.2. Connection to a Production Database 29.1.3. Connection to a JNDI DataSource 29.2. Using JdbcTemplate 29.3. JPA and “Spring Data” 29.3.1. Entity Classes 29.3.2. Spring Data JPA Repositories 29.3.3. Creating and Dropping JPA Databases 29.3.4. Open EntityManager in View 29.4. Using H2’s Web Console 29.4.1. Changing the H2 Console’s Path 29.5. Using jOOQ 29.5.1. Code Generation 29.5.2. Using DSLContext 29.5.3. jOOQ SQL Dialect 29.5.4. Customizing jOOQ 30. Working with NoSQL Technologies 30.1. Redis 30.1.1. Connecting to Redis 30.2. MongoDB 30.2.1. Connecting to a MongoDB Database 30.2.2. MongoTemplate 30.2.3. Spring Data MongoDB Repositories 30.2.4. Embedded Mongo 30.3. Neo4j 30.3.1. Connecting to a Neo4j Database 30.3.2. Using the Embedded Mode 30.3.3. Neo4jSession 30.3.4. Spring Data Neo4j Repositories 30.3.5. Repository Example 30.4. Gemfire 30.5. Solr 30.5.1. Connecting to Solr 30.5.2. Spring Data Solr Repositories 30.6. Elasticsearch 30.6.1. Connecting to Elasticsearch by Using Jest 30.6.2. Connecting to Elasticsearch by Using Spring Data 30.6.3. Spring Data Elasticsearch Repositories 30.7. Cassandra 30.7.1. Connecting to Cassandra 30.7.2. Spring Data Cassandra Repositories 30.8. Couchbase 30.8.1. Connecting to Couchbase 30.8.2. Spring Data Couchbase Repositories 30.9. LDAP 30.9.1. Connecting to an LDAP Server 30.9.2. Spring Data LDAP Repositories 30.9.3. Embedded In-memory LDAP Server 30.10. InfluxDB 30.10.1. Connecting to InfluxDB 31. Caching 31.1. Supported Cache Providers 31.1.1. Generic 31.1.2. JCache (JSR-107) 31.1.3. EhCache 2.x 31.1.4. Hazelcast 31.1.5. Infinispan 31.1.6. Couchbase 31.1.7. Redis 31.1.8. Caffeine 31.1.9. Simple 31.1.10. None 32. Messaging 32.1. JMS 32.1.1. ActiveMQ Support 32.1.2. Artemis Support 32.1.3. Using a JNDI ConnectionFactory 32.1.4. Sending a Message 32.1.5. Receiving a Message 32.2. AMQP 32.2.1. RabbitMQ support 32.2.2. Sending a Message 32.2.3. Receiving a Message 32.3. Apache Kafka Support 32.3.1. Sending a Message 32.3.2. Receiving a Message 32.3.3. Additional Kafka Properties 33. Calling REST Services with RestTemplate 33.1. RestTemplate Customization 34. Calling REST Services with WebClient 34.1. WebClient Customization 35. Validation 36. Sending Email 37. Distributed Transactions with JTA 37.1. Using an Atomikos Transaction Manager 37.2. Using a Bitronix Transaction Manager 37.3. Using a Narayana Transaction Manager 37.4. Using a Java EE Managed Transaction Manager 37.5. Mixing XA and Non-XA JMS Connections 37.6. Supporting an Alternative Embedded Transaction Manager 38. Hazelcast 39. Quartz Scheduler 40. Spring Integration 41. Spring Session 42. Monitoring and Management over JMX 43. Testing 43.1. Test Scope Dependencies 43.2. Testing Spring Applications 43.3. Testing Spring Boot Applications 43.3.1. Detecting Web Application Type 43.3.2. Detecting Test Configuration 43.3.3. Excluding Test Configuration 43.3.4. Testing with a running server 43.3.5. Using JMX 43.3.6. Mocking and Spying Beans 43.3.7. Auto-configured Tests 43.3.8. Auto-configured JSON Tests 43.3.9. Auto-configured Spring MVC Tests 43.3.10. Auto-configured Spring WebFlux Tests 43.3.11. Auto-configured Data JPA Tests 43.3.12. Auto-configured JDBC Tests 43.3.13. Auto-configured jOOQ Tests 43.3.14. Auto-configured Data MongoDB Tests 43.3.15. Auto-configured Data Neo4j Tests 43.3.16. Auto-configured Data Redis Tests 43.3.17. Auto-configured Data LDAP Tests 43.3.18. Auto-configured REST Clients 43.3.19. Auto-configured Spring REST Docs Tests Auto-configured Spring REST Docs Tests with Mock MVC Auto-configured Spring REST Docs Tests with REST Assured 43.3.20. User Configuration and Slicing 43.3.21. Using Spock to Test Spring Boot Applications 43.4. Test Utilities 43.4.1. ConfigFileApplicationContextInitializer 43.4.2. TestPropertyValues 43.4.3. OutputCapture 43.4.4. TestRestTemplate 44. WebSockets 45. Web Services 46. Creating Your Own Auto-configuration 46.1. Understanding Auto-configured Beans 46.2. Locating Auto-configuration Candidates 46.3. Condition Annotations 46.3.1. Class Conditions 46.3.2. Bean Conditions 46.3.3. Property Conditions 46.3.4. Resource Conditions 46.3.5. Web Application Conditions 46.3.6. SpEL Expression Conditions 46.4. Testing your Auto-configuration 46.4.1. Simulating a Web Context 46.4.2. Overriding the Classpath 46.5. Creating Your Own Starter 46.5.1. Naming 46.5.2. autoconfigure Module 46.5.3. Starter Module 47. Kotlin support 47.1. Requirements 47.2. Null-safety 47.3. Kotlin API 47.3.1. runApplication 47.3.2. Extensions 47.4. Dependency management 47.5. @ConfigurationProperties 47.6. Testing 47.7. Resources 47.7.1. Further reading 47.7.2. Examples 48. What to Read Next V. Spring Boot Actuator: Production-ready features 49. Enabling Production-ready Features 50. Endpoints 50.1. Enabling Endpoints 50.2. Exposing Endpoints 50.3. Securing HTTP Endpoints 50.4. Configuring Endpoints 50.5. Hypermedia for Actuator Web Endpoints 50.6. Actuator Web Endpoint Paths 50.7. CORS Support 50.8. Implementing Custom Endpoints 50.8.1. Receiving Input Input type conversion 50.8.2. Custom Web Endpoints Web Endpoint Request Predicates Path HTTP method Consumes Produces Web Endpoint Response Status Web Endpoint Range Requests Web Endpoint Security 50.8.3. Servlet endpoints 50.8.4. Controller endpoints 50.9. Health Information 50.9.1. Auto-configured HealthIndicators 50.9.2. Writing Custom HealthIndicators 50.9.3. Reactive Health Indicators 50.9.4. Auto-configured ReactiveHealthIndicators 50.10. Application Information 50.10.1. Auto-configured InfoContributors 50.10.2. Custom Application Information 50.10.3. Git Commit Information 50.10.4. Build Information 50.10.5. Writing Custom InfoContributors 51. Monitoring and Management over HTTP 51.1. Customizing the Management Endpoint Paths 51.2. Customizing the Management Server Port 51.3. Configuring Management-specific SSL 51.4. Customizing the Management Server Address 51.5. Disabling HTTP Endpoints 52. Monitoring and Management over JMX 52.1. Customizing MBean Names 52.2. Disabling JMX Endpoints 52.3. Using Jolokia for JMX over HTTP 52.3.1. Customizing Jolokia 52.3.2. Disabling Jolokia 53. Loggers 53.1. Configure a Logger 54. Metrics 54.1. Getting started 54.2. Supported monitoring systems 54.2.1. Atlas 54.2.2. Datadog 54.2.3. Ganglia 54.2.4. Graphite 54.2.5. Influx 54.2.6. JMX 54.2.7. New Relic 54.2.8. Prometheus 54.2.9. SignalFx 54.2.10. Simple 54.2.11. StatsD 54.2.12. Wavefront 54.3. Supported Metrics 54.3.1. Spring MVC Metrics 54.3.2. Spring WebFlux Metrics 54.3.3. RestTemplate Metrics 54.3.4. Cache Metrics 54.3.5. DataSource Metrics 54.3.6. RabbitMQ Metrics 54.4. Registering custom metrics 54.5. Customizing individual metrics 54.5.1. Per-meter properties 54.6. Metrics endpoint 55. Auditing 56. HTTP Tracing 56.1. Custom HTTP tracing 57. Process Monitoring 57.1. Extending Configuration 57.2. Programmatically 58. Cloud Foundry Support 58.1. Disabling Extended Cloud Foundry Actuator Support 58.2. Cloud Foundry Self-signed Certificates 58.3. Custom context path 59. What to Read Next VI. Deploying Spring Boot Applications 60. Deploying to the Cloud 60.1. Cloud Foundry 60.1.1. Binding to Services 60.2. Heroku 60.3. OpenShift 60.4. Amazon Web Services (AWS) 60.4.1. AWS Elastic Beanstalk Using the Tomcat Platform Using the Java SE Platform 60.4.2. Summary 60.5. Boxfuse and Amazon Web Services 60.6. Google Cloud 61. Installing Spring Boot Applications 61.1. Supported Operating Systems 61.2. Unix/Linux Services 61.2.1. Installation as an init.d Service (System V) Securing an init.d Service 61.2.2. Installation as a systemd Service 61.2.3. Customizing the Startup Script Customizing the Start Script when It Is Written Customizing a Script When It Runs 61.3. Microsoft Windows Services 62. What to Read Next VII. Spring Boot CLI 63. Installing the CLI 64. Using the CLI 64.1. Running Applications with the CLI 64.1.1. Deduced “grab” Dependencies 64.1.2. Deduced “grab” Coordinates 64.1.3. Default Import Statements 64.1.4. Automatic Main Method 64.1.5. Custom Dependency Management 64.2. Applications with Multiple Source Files 64.3. Packaging Your Application 64.4. Initialize a New Project 64.5. Using the Embedded Shell 64.6. Adding Extensions to the CLI 65. Developing Applications with the Groovy Beans DSL 66. Configuring the CLI with settings.xml 67. What to Read Next VIII. Build tool plugins 68. Spring Boot Maven Plugin 68.1. Including the Plugin 68.2. Packaging Executable Jar and War Files 69. Spring Boot Gradle Plugin 70. Spring Boot AntLib Module 70.1. Spring Boot Ant Tasks 70.1.1. spring-boot:exejar 70.1.2. Examples 70.2. spring-boot:findmainclass 70.2.1. Examples 71. Supporting Other Build Systems 71.1. Repackaging Archives 71.2. Nested Libraries 71.3. Finding a Main Class 71.4. Example Repackage Implementation 72. What to Read Next IX. ‘How-to’ guides 73. Spring Boot Application 73.1. Create Your Own FailureAnalyzer 73.2. Troubleshoot Auto-configuration 73.3. Customize the Environment or ApplicationContext Before It Starts 73.4. Build an ApplicationContext Hierarchy (Adding a Parent or Root Context) 73.5. Create a Non-web Application 74. Properties and Configuration 74.1. Automatically Expand Properties at Build Time 74.1.1. Automatic Property Expansion Using Maven 74.1.2. Automatic Property Expansion Using Gradle 74.2. Externalize the Configuration of SpringApplication 74.3. Change the Location of External Properties of an Application 74.4. Use ‘Short’ Command Line Arguments 74.5. Use YAML for External Properties 74.6. Set the Active Spring Profiles 74.7. Change Configuration Depending on the Environment 74.8. Discover Built-in Options for External Properties 75. Embedded Web Servers 75.1. Use Another Web Server 75.2. Disabling the Web Server 75.3. Configure Jetty 75.4. Add a Servlet, Filter, or Listener to an Application 75.4.1. Add a Servlet, Filter, or Listener by Using a Spring Bean Disable Registration of a Servlet or Filter 75.4.2. Add Servlets, Filters, and Listeners by Using Classpath Scanning 75.5. Change the HTTP Port 75.6. Use a Random Unassigned HTTP Port 75.7. Discover the HTTP Port at Runtime 75.8. Configure SSL 75.9. Configure HTTP/2 75.9.1. HTTP/2 with Undertow 75.9.2. HTTP/2 with Jetty 75.9.3. HTTP/2 with Tomcat 75.10. Configure Access Logging 75.11. Running Behind a Front-end Proxy Server 75.11.1. Customize Tomcat’s Proxy Configuration 75.12. Configure Tomcat 75.13. Enable Multiple Connectors with Tomcat 75.14. Use Tomcat’s LegacyCookieProcessor 75.15. Configure Undertow 75.16. Enable Multiple Listeners with Undertow 75.17. Create WebSocket Endpoints Using @ServerEndpoint 75.18. Enable HTTP Response Compression 76. Spring MVC 76.1. Write a JSON REST Service 76.2. Write an XML REST Service 76.3. Customize the Jackson ObjectMapper 76.4. Customize the @ResponseBody Rendering 76.5. Handling Multipart File Uploads 76.6. Switch Off the Spring MVC DispatcherServlet 76.7. Switch off the Default MVC Configuration 76.8. Customize ViewResolvers 77. HTTP Clients 77.1. Configure RestTemplate to Use a Proxy 78. Logging 78.1. Configure Logback for Logging 78.1.1. Configure Logback for File-only Output 78.2. Configure Log4j for Logging 78.2.1. Use YAML or JSON to Configure Log4j 2 79. Data Access 79.1. Configure a Custom DataSource 79.2. Configure Two DataSources 79.3. Use Spring Data Repositories 79.4. Separate @Entity Definitions from Spring Configuration 79.5. Configure JPA Properties 79.6. Configure Hibernate Naming Strategy 79.7. Use a Custom EntityManagerFactory 79.8. Use Two EntityManagers 79.9. Use a Traditional persistence.xml File 79.10. Use Spring Data JPA and Mongo Repositories 79.11. Expose Spring Data Repositories as REST Endpoint 79.12. Configure a Component that is Used by JPA 79.13. Configure jOOQ with Two DataSources 80. Database Initialization 80.1. Initialize a Database Using JPA 80.2. Initialize a Database Using Hibernate 80.3. Initialize a Database 80.4. Initialize a Spring Batch Database 80.5. Use a Higher-level Database Migration Tool 80.5.1. Execute Flyway Database Migrations on Startup 80.5.2. Execute Liquibase Database Migrations on Startup 81. Messaging 81.1. Disable Transacted JMS Session 82. Batch Applications 82.1. Execute Spring Batch Jobs on Startup 83. Actuator 83.1. Change the HTTP Port or Address of the Actuator Endpoints 83.2. Customize the ‘whitelabel’ Error Page 84. Security 84.1. Switch off the Spring Boot Security Configuration 84.2. Change the UserDetailsService and Add User Accounts 84.3. Enable HTTPS When Running behind a Proxy Server 85. Hot Swapping 85.1. Reload Static Content 85.2. Reload Templates without Restarting the Container 85.2.1. Thymeleaf Templates 85.2.2. FreeMarker Templates 85.2.3. Groovy Templates 85.3. Fast Application Restarts 85.4. Reload Java Classes without Restarting the Container 86. Build 86.1. Generate Build Information 86.2. Generate Git Information 86.3. Customize Dependency Versions 86.4. Create an Executable JAR with Maven 86.5. Use a Spring Boot Application as a Dependency 86.6. Extract Specific Libraries When an Executable Jar Runs 86.7. Create a Non-executable JAR with Exclusions 86.8. Remote Debug a Spring Boot Application Started with Maven 86.9. Build an Executable Archive from Ant without Using spring-boot-antlib 87. Traditional Deployment 87.1. Create a Deployable War File 87.2. Convert an Existing Application to Spring Boot 87.3. Deploying a WAR to WebLogic 87.4. Use Jedis Instead of Lettuce X. Appendices A. Common application properties B. Configuration Metadata B.1. Metadata Format B.1.1. Group Attributes B.1.2. Property Attributes B.1.3. Hint Attributes B.1.4. Repeated Metadata Items B.2. Providing Manual Hints B.2.1. Value Hint B.2.2. Value Providers Any Class Reference Handle As Logger Name Spring Bean Reference Spring Profile Name B.3. Generating Your Own Metadata by Using the Annotation Processor B.3.1. Nested Properties B.3.2. Adding Additional Metadata C. Auto-configuration classes C.1. From the “spring-boot-autoconfigure” module C.2. From the “spring-boot-actuator-autoconfigure” module D. Test auto-configuration annotations E. The Executable Jar Format E.1. Nested JARs E.1.1. The Executable Jar File Structure E.1.2. The Executable War File Structure E.2. Spring Boot’s “JarFile” Class E.2.1. Compatibility with the Standard Java “JarFile” E.3. Launching Executable Jars E.3.1. Launcher Manifest E.3.2. Exploded Archives E.4. PropertiesLauncher Features E.5. Executable Jar Restrictions E.6. Alternative Single Jar Solutions F. Dependency versions
1,01.zipOutput显示所有的调试信息(5KB)2,02.zipSome general debugging tips一般的调试技巧(11KB)3,03.zipDebugging ISAPI extension调试ISAPI扩展(4KB)4,04.zipLibDump类似DumpBin的工具(10KB)5,05.zipFinding memory leaks发现内存的泄漏(6KB)6,06.zipConvert message ID to a string将消息标志符转换成字符串(4KB)7,07.zipMessage Tracer消息跟踪(5KB)8,08.zipA simple profiler class一个简单的轮廓类(5KB)9,09.zipTerminator中断应用程序(5KB)10,10.zipTranslate Window Style转换窗口风格(5KB)11,11.zipLong String Debugging Macro调试宏(5KB)12,12.zipCheck for loaded DLLs检查装入的动态链接库(4KB)13,13.zipAutoincreasing build number自动增加版本信息的宏(5KB)14,14.zipFile Dialog Macro文件对话框宏(6KB)15,15.zipCode Template add-in for Visual C++ 5.0在VC5中可增加的代码模板(5KB)16,16.zipComment / Uncomment macros命令/反命令宏(5KB)17,17.zipCustom built files自定义生成的文件(5KB)18,18.zipDefine Method定义方法(5KB)19,19.zipExport Makefile输出工程制作文件(5KB)20,20.zipJump to Next/Previous Function Definition跳转到下一个/上一个功能定义(4KB)21,21.zipInverting Assignment Operations转化操作任务(5KB)22,22.zipVC4.2 style keyboard macro recorder for DevStudio 97在DevStudio 97中使用在VC4.2风格的键盘宏记录(4KB)23,23.zipApplication Launcher程序发射器, 能够在Word, Excel, Access, Power Point, Visio和Html中连接网站(6KB)24,24.zipOpen current header file打开当前文件头(7KB)25,25.zipOpen header file打开文件头(4KB)26,26.zipSequentially Renumber Resource ID's重新对资源标识符编号(5KB)27,27.zipA secondary clipboard实现第二个剪贴板, 不过它用的热键是Ctrl+Shift+C, Ctrl+Shift+V和Ctrl+Shift+X(4KB)28,28.zipCase switching这个宏实现文字的大小写互换(4KB)29,29.zipWM_COMMAND user message macroWM_COMMAND用户消息宏(5KB)30,30.zipBetter caret movement by words在IDE中移动快速单词的宏(5KB)

62,073

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术交流专区
javascript云原生 企业社区
社区管理员
  • ASP.NET
  • .Net开发者社区
  • R小R
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

.NET 社区是一个围绕开源 .NET 的开放、热情、创新、包容的技术社区。社区致力于为广大 .NET 爱好者提供一个良好的知识共享、协同互助的 .NET 技术交流环境。我们尊重不同意见,支持健康理性的辩论和互动,反对歧视和攻击。

希望和大家一起共同营造一个活跃、友好的社区氛围。

试试用AI创作助手写篇文章吧