We were discussing Flink Apis and connector:

A typical query looks like this:



env.readTextFile(ratingsCsvPath)



.flatMap(new ExtractRating())



            .groupBy(0)



            .sum(1)



            .print();



There are connectors for different data sources which can be passed in via addSource



In order to add parallelization, that governs the tasks, replicas and runtime, we can set it globally with env.setParallelism(dop) ;



Otherwise we can set it at the DataSet API



There is even a similar method to set the maximum parallelism. This would prevent the parallelism from going beyond the limit



The newer DataStream API allows methods such as: assignTimestampsAndWatermarks because it supports the watermark and allows the ordering of the events in the stream. A sink can be added to write the events to store.



The Flink connector library for Pravega adds a data source and sink for use with the Flink Dara API.



The Flink Pravega Writer and Flink Pravega Reader work with generic events as long as the events implement serializability and de-serializability  respectively.



The FlinkPravegaWriter extends RichSinkFunction and implements ListCheckpointed and CheckpointListener interfaces.



The FlinkPravegaReader extends RichParallelSourceFunction implements ResultTypeQueryable, StoppableFunction and ExternallyInducedSource interfaces.



Notice the extension of  RichParallelSourceFunction from Flink is meant for high scalability from reader groups. This is required in use case such as reading from socket where the data may arrive at a fast rate

Flink has a construct for WindowJoin where it can relate two entities within a window. The two sides toa join may have different rates of arrival so the output may not always be the same, but the output of the join will follow a format.
The word count is inherently summation form. This means it can be parallelized by splitting data. If the data arrives on a socket, it just needs to do a map and reduce. For example, the SockerWindowWordCount example in the flink source code repository makes use of a flatMap function that translates a string to a dictionary of word and frequency.  The reduce function in this case, merely combines the count from the flatMap for the same word.
We can also create a trigger since the examples are data driven. This trigger calculates a delta or difference between the datapoint that triggered the last and the current datapoint. It the delta is higher than a threshold, the trigger fires. A delta function and a threshold is required for the trigger to work.
The delta function comes in useful for cumulative values because the path of change does not matter except the initial and final values. For example, the cumulative value is always monotonic for positive values. It can climb at different rates but the final value will be at the same or higher level than the initial value. We can take the delta function in this case, to suitably determine a threshold. The word counts are all positive values Therefore a trigger is suitable for a parallelized Flink word count example when we are interested in queries where thresholds are exceeded first.

A methodology to use Flink APIs for text summarization:
Text summarization has been treated as a multi-stage processing of a problem starting with word-vectorization, followed by SoftMax classification and keyword extraction and ending with salient sentences, projected as the summary. These stages may be numerous and each stage may involve multiple operations simultaneously such as when text classification and bounding box regression are run simultaneously.  Most of the stages are also batch oriented where-as the Flink APIs are known for their suitability to streaming operations. Yet the data that appears in a text regardless of its length is inherently a stream. If the Flink APIs can count words in a stream of text, then it can be applied with sophisticated operators to the same stream of text for text summarization.
With this motivation, this article tries to look for the application of Flink APIs towards text summarization starting with light-weight peripheral application to become more intrinsic to the text summarization solution.
Flink APIs give the comfort of choosing from a wide variety of transforming operators including map and reduce like operators and with first class standard query operators over Table API. In addition, they support data representation in tabular as well as graph forms by providing abstractions for both.  Words and their neighbors can easily by represented as vertices and weighted edges of a graph so long as the weights are found and applied to the edges. The finding of weights such as with SoftMax classification from neural net is well-known and outside the scope of this article. With the graph once established for a given text, Flink APIs can be used to work with the graphs to determine the vertices based on centrality and then the extraction of sentences according to those keywords and their positional relevance. We focus on this latter part.
For example, we can use the following technique to find the shortest path between two candidates:
final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
env.fromCollection(List<Tuple2<Edges, Integer>> tuples) 
            .flatMap(new ExtractWeights())
            .keyBy(0)
            .timeWindow(Time.seconds(30))
            .sum(1)
            .filter(new FilterWeights())
            .timeWindowAll(Time.seconds(30))
            .apply(new GetTopWeights())
            .print();
We can even use single-source shortest path for a classification. It might involve multiple iterations with at least one pass for each vertex as source:
SingleSourceShortestPaths<Integer, NullValue> singleSourceShortestPaths = new SingleSourceShortestPaths<>(sourceVertex, maxIterations);
Advanced techniques may utilize streaming graph operators that are not restricted by the size of the graph and are first-class operators over graph.

We were discussing Flink Apis and connector:
A typical query looks like this:

env.readTextFile(ratingsCsvPath)

.flatMap(new ExtractRating())

            .groupBy(0)

            .sum(1)

            .print();

There are connectors for different data sources which can be passed in via addSource

In order to add parallelization, that governs the tasks, replicas and runtime, we can set it globally with env.setParallelism(dop) ;

Otherwise we can set it at the DataSet API

There is even a similar method to set the maximum parallelism. This would prevent the parallelism from going beyond the limit

The newer DataStream API allows methods such as: assignTimestampsAndWatermarks because it supports the watermark and allows the ordering of the events in the stream. A sink can be added to write the events to store.

The Flink connector library for Pravega adds a data source and sink for use with the Flink Dara API.

The Flink Pravega Writer and Flink Pravega Reader work with generic events as long as the events implement serializability and de-serializability  respectively.

The FlinkPravegaWriter extends RichSinkFunction and implements ListCheckpointed and CheckpointListener interfaces.

The FlinkPravegaReader extends RichParallelSourceFunction implements ResultTypeQueryable, StoppableFunction and ExternallyInducedSource interfaces.

Notice the extension of  RichParallelSourceFunction from Flink is meant for high scalability from reader groups. This is required in use case such as reading from socket where the data may arrive at a fast rate

The solutions that are built on top of SQL queries are not necessarily looking to write SQL. They want programmability and are just as content to write code using Table API as they are with SQL queries. Consequently, business intelligence and CRM solutions are writing their code with standard query operators over their data. These well-defined operators are applicable to most collections of data and the notion is shared with other programming lConsistency also places hard requirements on the choice of the processing. Strict consistency has traditionally been associated with relational databases. Eventual consistency has been made possible in distributed storage with the help of messaging algorithms such as Paxos. Big Data is usually associated with eventual consistency.anguages such as. Net.
Partitioning is probably the reason why tools like Spark, Flink becomes popular for BigData:
Apache Flink provides a SQL abstraction over its Table API. It also provides syntax fo make use of Partitioning and increase parallelism.
The Apache Flink provides the ability to read from various data sources such as env.readFromFile, env.readFromCollection and readFromInput while allowing read and write from streams via connector.

A typical query looks like this:

env.readTextFile(ratingsCsvPath)

.flatMap(new ExtractRating())

            .groupBy(0)

            .sum(1)

            .print();

There are connectors for different data sources which can be passed in via addSource

In order to add parallelization, that governs the tasks, replicas and runtime, we can set it globally with env.setParallelism(dop) ;

Otherwise we can set it at the DataSet API

There is even a similar method to set the maximum parallelism. This would prevent the parallelism from going beyond the limit

The newer DataStream API allows methods such as: assignTimestampsAndWatermarks because it supports the watermark and allows the ordering of the events in the stream. A sink can be added to write the events to store.

The Flink connector library for Pravega adds a data source and sink for use with the Flink Dara API. 

The Flink Pravega Writer and Flink Pravega Reader work with generic events as long as the events implement serializability and de-serializability  respectively.

The FlinkPravegaWriter extends RichSinkFunction and implements ListCheckpointed and CheckpointListener interfaces.

The FlinkPravegaReader extends RichParallelSourceFunction implements ResultTypeQueryable, StoppableFunction and ExternallyInducedSource interfaces. 

Notice the extension of  RichParallelSourceFunction from Flink is meant for high scalability from reader groups. This is required in use case such as reading from socket where the data may arrive at a fast rate 

Apache Flink discussion continued:
Apache Spark query code and Apache Flink query code look very much similar, the former uses stream processing as a special case of batch processing while the latter does just the reverse.
Also Apache Flink provides a SQL abstraction over its Table API
The Apache Flink provides the ability to read from various data sources such as env.readFromFile, env.readFromCollection and readFromInput while allowing read and write from streams via connector.
Some more Flink Queries with examples below:
1) final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
2) env.fromCollection(List<Tuple2<String, Integer>> tuples)
3)             .flatMap(new ExtractHashTags())
4)             .keyBy(0)
5)             .timeWindow(Time.seconds(30))
6)             .sum(1)
7)             .filter(new FilterHashTags())
8)             .timeWindowAll(Time.seconds(30))
9)             .apply(new GetTopHashTag())
10)             .print();
The Get top hash tag merely picks out the hash tag with the most count.
Notice the methods applied to the DataSet follow one after the other. This is a preferred convention for Flink
Since we use fromCollection, it does not have parallelism.
We can improve parallelism with fromParallelCollection
If we want to find a distribution, we can do something like :
env.readTextFile(ratingsCsvPath)
.flatMap(new ExtractRating())
            .groupBy(0)
            .sum(1)
            .print();
Here is the quintessential wordcount:
lines.flatMap((line, out) -> {
            String[] words = line.split("\\W+");
            for (String word : words) {
                out.collect(new Tuple2<>(word, 1));
            }
        })
        .returns(new TupleTypeInfo(TypeInformation.of(String.class), TypeInformation.of(Integer.class)))
        .groupBy(0)
        .sum(1)
        .print();

Flink also supports graphs, vertices and edges with:
import org.apache.flink.graph.Edge;
import org.apache.flink.graph.Graph;
import org.apache.flink.graph.Vertex;
Graph<Integer, NullValue, NullValue> followersGraph = Graph.fromDataSet(socialMediaEdgeSet, env);
We may need weighted graphs to run single source shortest path:
SingleSourceShortestPaths<Integer, NullValue> singleSourceShortestPaths = new SingleSourceShortestPaths<>(sourceVertex, maxIterations);
     

There are connectors for different data sources which can be passed in via addSource

A comparision of Flink SQL execution and Facebook’s Presto continued:



The Flink Application provides the ability to write SQL query expressions. This abstraction works closely with the Table API and SQL queries can be executed over tables. The Table API is a language centered around tables and follows a relational model. Tables have a schema attached and the API provides the relational operators of selection, projection and join. Programs written with Table API go through an optimizer that applies optimization rules before execution.



Presto from Facebook is  a distributed SQL query engine can operate on streams from various data source supporting adhoc queries in near real-time.



Just like the standard query operators of .Net the FLink SQL layer is merely a convenience over the table APIs. On the other hand, Presto offers to run over any kind of data source not just Table APIs.



Although Apache Spark query code and Apache Flink query code look very much similar, the former uses stream processing as a special case of batch processing while the latter does just the reverse.

Also Apache Flink provides a SQL abstraction over its Table API


While Apache Spark provided ".map(...)" and  ".reduce(...)" programmability syntax to support batch oriented processing, Apache Flink provides Table APIs with  ".groupby(...)" and  ".order(...)" syntax. It provides SQL abstraction and supports steam processing as the norm. 

Flink Savepoint versus checkpoint
Frequently Apache Flink software users find the tasks they submit to the Flink runtime to run long. This happens when the data that these tasks process is very large. There are usually more than one tasks that perform the same operation by dividing the data among themselves. These tasks do not perform in batch operations. They are most likely performing stream-based operations handling a window at a time. The state of the Flink application can be persisted with savepoints. This is something that the application can configure the tasks before they run.  Tasks are usually run as part of Flink ‘jobs’ depending on the parallelism set by the application. The savepoint is usually stored as a set of files under the <base>/.flink/savepoint folder
Savepoints can be manually generated from running link jobs with the following command:
# ./bin/flink savepoint <jobID>
The checkpoints are system generated. The do not depend on the user. The checkpoints are also written to the file system much the same way as savepoints. Although they use different names and are meant to be triggered by user versus system, they share the system method to persist state for any jobs as long as those jobs are enumerable.
The list of running jobs can be seen from the command line with
# ./bin/flink list –r
where the –r option is an option to list the running jobs
Since the code to persist savepoint and checkpoints are the same, the persistence of the state needs to follow the policies of the system which include a limit on the number of states an application can persist.
This implies that the manual savepointing will fail if the limits are violated.  This results in all savepoint triggers to fail. The configuration of savepointing and checkpointing is described by the Apache Flink documentation. Checkpointing may also be possible with the reader group for the stream store. It's limits may need to be honored as well.
User has syntax from Flink such as savepoints to interpret progress.  Users can create, own or delete savepoints which represents the execution state of a streaming job. These savepoints point to actual files on the storage. Flink provides checkpointing which it creates and deletes without user intervention.
While checkpoints are focused on recovery, much more lightweight than savepoints, and bound to the job lifetime, they can become equally efficient diagnostic mechanisms
The detection of failed savepoints is clear from both the jobManager logs as well as the taskManager logs. Shell execution of the flink command for savepoints is run from the jobManager where the flink binary is available. The logs are conveniently available in the log directory.

A comparision of Flink SQL execution and Facebook’s Presto continued:

The Flink Application provides the ability to write SQL query expressions. This abstraction works closely with the Table API and SQL queries can be executed over tables. The Table API is a language centered around tables and follows a relational model. Tables have a schema attached and the API provides the relational operators of selection, projection and join. Programs written with Table API go through an optimizer that applies optimization rules before execution.

Presto from Facebook is  a distributed SQL query engine can operate on streams from various data source supporting adhoc queries in near real-time.
Microsoft facilitated streaming operators with StreamInsight queries. The Microsoft StreamInsight Queries follow a five-step procedure:
1)     define events in terms of payload as the data values of the event and the shape as the lifetime of the event along the time axis
2)     define the input streams of the event as a function of the event payload and shape. For example, this could be a simple enumerable over some time interval
3)     Based on the events definitions and the input stream, determine the output stream and express it as a query. In a way this describes a flow chart for the query
4)     Bind the query to a consumer. This could be to a console. For example
        Var query = from win in inputStream.TumblingWindow( TimeSpan.FromMinutes(3)) select win.Count();
5)     Run the query and evaluate it based on time.
The StreamInsight queries can be written with .Net and used with standard query operators. The use of ‘WindowedDataStream’ in Flink Applications and TumblingWindow in .Net are constructs that allow operation on stream based on a window at a time.

Just like the standard query operators of .Net the FLink SQL layer is merely a convenience over the table APIs. On the other hand, Presto offers to run over any kind of data source not just Table APIs.

Although Apache Spark query code and Apache Flink query code look very much similar, the former uses stream processing as a special case of batch processing while the latter does just the reverse.
Also Apache Flink provides a SQL abstraction over its Table API

A comparision of Flink SQL execution and Facebook’s Presto continued:
The Flink Application provides the ability to write SQL query expressions. This abstraction works closely with the Table API and SQL queries can be executed over tables. The Table API is a language centered around tables and follows a relational model. Tables have a schema attached and the API provides the relational operators of selection, projection and join. Programs written with Table API go through an optimizer that applies optimization rules before execution.
Presto from Facebook is  a distributed SQL query engine can operate on streams from various data source supporting adhoc queries in near real-time.
Consider the time and space dimension queries that are generally required in dashboards, charts and graphs. These queries need to search over data that has been accumulated which might be quite large often exceeding terabytes. As the data grows, the metadata becomes all the more important and their organization can now be tailored to the queries instead of relying on the organization of the data. If there is need to separate online adhoc queries on current metadata from more analytical and intensive background queries, then we can choose to have different organizations of the information in each category so that they serve their queries better.
SQL queries have dominated almost all databases and warehouses queries no matter how high the software stack has been built over these products. On the other hand, simple summation form logic on big data need to be written with Map-Reduce methods. Although query languages such as U-SQL are trying to bridge the gap and adapters are written to translate SQL queries over other forms of data stores, they are not native to the unstructured stores and they often come up with their own query language.
The language for the query has traditionally been SQL. Tools like LogParser allow SQL queries to be executed over enumerable. SQL has been supporting user defined operators for a while now. These user defined operators help with additional computations that are not present as built-ins. In the case of relational data, these generally have been user defined functions or user defined aggregates. With the enumerable data set, the SQL is somewhat limited for LogParser. Any implementation of a query execution layer over the key value collection could choose to allow or disallow user defined operators. These enable computation on say user defined data types that are not restricted by the system defined types. Such types have been useful with say spatial co-ordinates or geographical data for easier abstraction and simpler expression of computational logic. For example, vector addition can be done with user defined data types and user defined operators.
The solutions that are built on top of SQL queries are not necessarily looking to write SQL. They want programmability and are just as content to write code using Table API as they are with SQL queries. Consequently, business intelligence and CRM solutions are writing their code with standard query operators over their data. These well-defined operators are applicable to most collections of data and the notion is shared with other programming languages such as. Net.

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:

401) Build a product where the last mile before the release usually requires everyone to pitch in

402) Build a product where the pre-release efforts can never truly be separated from development efforts

403) Build a product where the last mile gathers unwanted attention even though they don’t have any direct dependence on the product.

 404) Build a product where the announcements become something to look forward to both for people building the product and those waiting for it outside.

405) Build a product where the process of building never truly becomes a joyful process.

406) Build a product where the release of a product is never really a starting point for the next version

407) Build a product where the last few weeks for the release is usually reserved for making the customer experience better rather than during the development

408) Build a product where the Murphy’s law seems to be more applicable towards the endgame

409) Build a product where the week after the release still manages to throw surprises.

410) Build a product where the customer celebrations of their success with the product adds joy to the work involved during development but the hands that made the product are no longer there.

411) Build a product where the innovations are from the intellectual  intellectual horse power as opposed to the forces shaping the product and find more maintenance down the road

412) Build a product where the people building their product leave a mark and recognition for themselves only to find it revisioned by the next batch

413) Build a product as a v1 in the market and the find the adage nothing remains unchanged holding more truth than ever before

414) Build a product where the product matures version after version and find its customers snowball with loyalty

415) Build a product where the establishment of a product allows ventures in sister products that also do well

416) Build a product where vendors vie to ship together.

417) Build a product where the knowledge about how the competitor products is never too far away.

418) Build a product where the patented innovations spawn open source substitutes and workarounds

419) Build a product where the dynamics of the people building the product shapes the product more than anything else

Partitioning is probably the reason why tools like Spark, Flink becomes popular for BigData:
Partition function of FLink can be demonstrated with the following:
final ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();
DataSet<Tuple2<Integer, Double>> sorted = env.readCsvFile("ratings.csv")
.ignoreFirstLine()
.includeFields(false, true, true, false)
.types(Long.class, Double.class)
.groupBy(0)
.reduceGroup(new GroupReduceFunction<Tuple2<Long, Double>, Tuple2<Long, Double>>() {
    @Override
    public void reduce(Iterable<Tuple2<Long, Double>> values, Collector<Tuple2<Long, Double>>out) throws Exception {
        Long movieId = null;
        double total = 0;
        int count = 0;
        for (Tuple2<Long, Double> value: iterable) {
            movieId = value.f0;
            total += value.f1;
            count++;
        }
        if (count > 50){
            Collector.collect(new Tuple2<>(movieId, total/count);
        }
    }
})
.partitionCustom(new Partitioner<Double>() {
    @Override
    public int partition(Double key, int numPartition) {
        return key.intValue() - 1;
    }
    }, 1);
}

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:

390) Build a product where people can learn about and hear others empowered in their work and the fan following grows.

391) Build a product where they have to wait for orphaned resourcesn cleanup before they can proceed with re-install.

392) Build a product where the users have to frequently run the installer and it doesn’t complete some of the times

393) Build a product where the software is blamed because the administrator was shy to read the manual

394) Build a product where the resources for the software provided by the customer does not meet the requirements.

395) Build a product where different parts of the software need to be installed differently and find that deployments are usually haphazard

396) Build a product where the installation on production environment is so elaborate that it requires planning, dry runs and coordination across teams

397) Build a product where every update is used to justify setting aside a day by the staff

398) Build a product where the reality and perception are deliberately kept different at a customer site

399) Build a product where the vision for the product is different from what the customer wants to use it for.

400) Build  product where the quirkiness of the product offers fodder for all kind of talks from conferences to board room meetings.

401. Build a product where the last mile before the release usually requires everyone to pitch in 

402. Build a product where the pre-release efforts can never truly be separated from development efforts 

403. Build a product where the last mile gathers unwanted attention even though they don’t have any direct dependence on the product. 

404.  Build a product where the announcements become something to look forward to both for people building the product and those waiting for it outside. 

405. Build a product where the process of building never truly becomes a joyful process. 

406. Build a product where the release of a product is never really a starting point for the next version 

407. Build a product where the last few weeks for the release is usually reserved for making the customer experience better rather than during the development 

408. Build a product where the Murphy’s law seems to be more applicable towards the endgame 

409. Build a product where the week after the release still manages to throw surprises. 

410. Build a product where the customer celebrations of their success with the product adds joy to the work involved during development but the hands that made the product are no longer there. 

A comparision of Flink SQL execution and Facebook’s Presto continued:

The Flink Application provides the ability to write SQL query expressions. This abstraction works closely with the Table API and SQL queries can be executed over tables. The Table API is a language centered around tables and follows a relational model. Tables have a schema attached and the API provides the relational operators of selection, projection and join. Programs written with Table API go through an optimizer that applies optimization rules before execution.

Presto from Facebook is  a distributed SQL query engine can operate on streams from various data source supporting adhoc queries in near real-time.

The querying of key value collection is handled natively as per the data store. This translates to a query popularly described in SQL language over relational store as a join where the key-values can be considered a table with columns as key and value pair. The desired keys to include in the predicate can be put in a separate temporary table holding just the keys of interest and a join can be performed between the two based on the match between the keys.

Without the analogy of the join, the key-value collections will require standard query operators like where clause which may test for a match against a set of keys. This is rather expensive compared to the join because we do this with a large list of key-values and possibly repeated iterations over the entire list for matches against one or more keys in the provided set.

Most key-value collections are scoped. They are not necessarily in a large global list. Such key-values become scoped to the document or the object. The document may be in one of two forms – Json and Xml. The Json format has its own query language referred to as jmesPath and the Xml also support path-based queries. When the key-values are scoped, they can be efficiently searched by an application using standard query operators without requiring the use of paths inherent to a document format as Json or Xml.

Presto scalability to processing petabytes of data is unparalled. And the use of a distributed SQL query engine also helps

int getKthAntiClockWise(int[] [] A, int m, int n, int k)
{
if (n <1 || m < 1) return -1;
if (k <= m)
    return A[0, k-1];
if (k <= n+m-1)
   return A[m-1, k-m];
if (k <= n+m-1+m-1)
   return A[n-1, (m-1-(k-(n+m-1)))] ;
if (k <= n+m-1+m-1+n-2)
   return A[0, n-1-(k-(n+m-1+m-1))];
return getKthAntiClockWise(Copy(A, (1,1,m-2,n-2)), m-2, n-2, k-(2*n+2*m-4)));
 // Copy uses System.arraycopy
}

A comparision of Flink SQL execution and Facebook’s Presto:
The Flink Application provides the ability to write SQL query expressions. This abstraction works closely with the Table API and SQL queries can be executed over tables. The Table API is a language centered around tables and follows a relational model. Tables have a schema attached and the API provides the relational operators of selection, projection and join. Programs written with Table API go through an optimizer that applies optimization rules before execution.
Flink Applications generally do not need to use the above abstraction of Table APIs and SQL layers. Instead they work directly on the Core APIs of DataStream (unbounded) and DataSet (bounded data set) APIs. These APIs provide the ability to perform stateful stream processing.
For example,
DataStream<String> lines = env.addSource( new FlinkKafkaConsumer<>(…)); // source
DataStream<Event> events = lines.map((line)->parse(line)); // transformation
DataStream<Statistics> stats = events.keyBy(“id”).timeWindow(Time.seconds(10)).apply(new MyWindowAggregationFunction());
stats.addsink(new BucketingSinkPath));
Presto from Facebook is  a distributed SQL query engine can operate on streams from various data source supporting adhoc queries in near real-time. It does not partition based on MapReduce and executes the query with a custom SQL execution engine written in Java. It has a pipelined data model that can run multiple stages at once while pipelining the data between stages as it become available. This reduces end to end time while maximizing parallelization via stages on large data sets. A co-ordinator taking the incoming the query from the user draws up the plan and the assignment of resources. Facebook’s Presto can run on large data sets of social media such as in the order of Petabytes. It can also run over HDFS for interactive graphics.
There is also a difference in the queries when we match a single key or many keys. For example, when we use == operator versus IN operator in the query statement, the size of the list of key-values to be iterated does not reduce. It's only the efficiency of matching one tuple with the set of keys in the predicate that improves when we us an IN operator because we don’t have to traverse the entire list multiple times. Instead each entry is matched against the set of keys in the predicate specified by the IN operator. The use of a join on the other hand reduces the size of the range significantly and gives the query execution a chance to optimize the plan.
Just like the standard query operators of .Net the FLink SQL layer is merely a convenience over the table APIs. On the other hand, Presto offers to run over any kind of data source not just Table APIs.

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:

380) Build a product with thought through dashboard and find the users gravitating to the page
381) Build a product with little or no styling and find the applications not gaining appeal
382) Build a product with specific investment towards stylesheets and see dramatic improvement in perception
383) Build a product with customizable styles and the partners become happy
384) Build a product with styles that can be changed and the s satisfaction grows among end-users.
385) Build a product with styles that suit groups and membership to the group grows
386) Build a product with logo that can be made into stickers to be offered as give away and theit becomes popular among the young professionals
387) Build a product with marketing events that become popular and the awareness increases
388) Build a product with partnerships where partners talk about the product and the fan following grows
389) Build a product with advocacy groups and training and the skilled users grow
390) Build a product where people can learn about and hear others empowered in their work and the fan following grows.
391) Build a product where they have to wait for orphaned resourcesn cleanup before they can proceed with re-install.
392) Build a product where the users have to frequently run the installer and it doesn’t complete some of the times
393) Build a product where the software is blamed because the administrator was shy to read the manual
394) Build a product where the resources for the software provided by the customer does not meet the requirements.
395) Build a product where different parts of the software need to be installed differently and find that deployments are usually haphazard
396) Build a product where the installation on production environment is so elaborate that it requires planning, dry runs and coordination across teams
397) Build a product where every update is used to justify setting aside a day by the staff
398) Build a product where the reality and perception are deliberately kept different at a customer site
399) Build a product where the vision for the product is different from what the customer wants to use it for.
400) Build  product where the quirkiness of the product offers fodder for all kind of talks from conferences to board room meetings.

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:
370) Build a product that gets a thumbs up from production support.
371) Build a product that makes it easy to add storage and find prolific use of storage by users.
372) Build a product that makes it easy for users to complete workflows with fewer checks and find that users tend to experiment rather than let the workflow guide them
373) Build a product that makes workflows too convoluted and users tend to use it only for partial completion
374) Build a product where users can create their own workflows and it becomes popular with audience that like user friendly designer software like tools
375) Build a product with little or no composition to workflows and users tend to write several clones of customized workflows
376) Build a product with the ability to support live debugging and it become popular for development environments
377) Build a product with lots of levers and the dashboard looks intimidating
378) Build a product with fewer levers and find the customers unhappy
379) Build a product where you let the users create their own panels for levers and they hardly do it
380) Build a product with thought through dashboard and find the users gravitating to the page
381) Build a product with little or no styling and find the applications not gaining appeal
382) Build a product with specific investment towards stylesheets and see dramatic improvement in perception
383) Build a product with customizable styles and the partners become happy
384) Build a product with styles that can be changed and the s satisfaction grows among end-users.
385) Build a product with styles that suit groups and membership to the group grows
386) Build a product with logo that can be made into stickers to be offered as give away and theit becomes popular among the young professionals
387) Build a product with marketing events that become popular and the awareness increases
388) Build a product with partnerships where partners talk about the product and the fan following grows
389) Build a product with advocacy groups and training and the skilled users grow
390) Build a product where people can learn about and hear others empowered in their work and the fan following grows.

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:
360) Build a product for different flavors of operating systems or cloud computing and find the developers struggle to keep their skills up to date on each flavor.
361) Build a product and realize it has to be modified for each and every platform on which it is run.
362) Build a product and which grows significantly and then retrofit adapters to different technologies.
363) Build a product and find a number of clients requiring customizations that ends up forming an infrastructure layer facing the clients
364) Build a product that proliferates layers and components as business expands only to have them shrink and adjust afterwards.
365) Build a product that makes it a challenge to reverse engineer
366) Build a product that reduces the surface area for foreign software to operate within its trust boundary
367) Build a product that lets it easy for applications to work inside the most stringent requirements customer sites
368) Build a product where the product cannot be remote accessed for troubleshooting due to customer -imposed restrictions
369) Build a product that makes it easy to diagnose issues or make remedies by flipping on or off configurations
370) Build a product that gets a thumbs up from production support.
371) Build a product that makes it easy to add storage and find prolific use of storage by users.
372) Build a product that makes it easy for users to complete workflows with fewer checks and find that users tend to experiment rather than let the workflow guide them
373) Build a product that makes workflows too convoluted and users tend to use it only for partial completion
374) Build a product where users can create their own workflows and it becomes popular with audience that like user friendly designer software like tools
375) Build a product with little or no composition to workflows and users tend to write several clones of customized workflows
376) Build a product with the ability to support live debugging and it become popular for development environments
377) Build a product with lots of levers and the dashboard looks intimidating
378) Build a product with fewer levers and find the customers unhappy
379) Build a product where you let the users create their own panels for levers and they hardly do it
380) Build a product with thought through dashboard and find the users gravitating to the page

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:

350) Build a product which becomes a Fortune 500 and gets to demand others to work with it
351) Build a product which has an easier path to growth due to its celebrity power
352) Build a product which gets accepted in industries because someone/some lobby opens doors
353) Build a product which struggles during it venture capital rounds but makes up for it with acquisition or going public
354) Build a product which has enormous appeal generated by word of mouth in academic circles
355) Build a product with high standards where the developers revel in fewer restrictions on resources and timeline and form a tight productive group
356) Build a product where there is proactive program management to keep the growth aligned to timelines and milestones
357) Build a product where the management deals with engineering problems in creative ways while the product is developed at the pace of the software development team
358) Build a product where the architecture team is responsible for ensuring no component is missed from the possibilities for the product and find the specifications to become obsolete before it can be revised.
359) Build a product where the growth and versioning of the product follows snowflake like pattern while the developers have to jump about from one branch to another
360) Build a product for different flavors of operating systems or cloud computing and find the developers struggle to keep their skills up to date on each flavor.
361) Build a product and realize it has to be modified for each and every platform on which it is run.
362) Build a product and which grows significantly and then retrofit adapters to different technologies.
363) Build a product and find a number of clients requiring customizations that ends up forming an infrastructure layer facing the clients
364) Build a product that proliferates layers and components as business expands only to have them shrink and adjust afterwards.
365) Build a product that makes it a challenge to reverse engineer
366) Build a product that reduces the surface area for foreign software to operate within its trust boundary
367) Build a product that lets it easy for applications to work inside the most stringent requirements customer sites
368) Build a product where the product cannot be remote accessed for troubleshooting due to customer -imposed restrictions
369) Build a product that makes it easy to diagnose issues or make remedies by flipping on or off configurations
370) Build a product that gets a thumbs up from production support.

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:



340) Build a product that builds fan following with its reliability.

341) Build a product that continuously raises the bar for the competition on Performance

342) Build a product that continuously stays in the limelight by finding one or another metric to claim to better at than the competitors.

343) Build a product that can resell part of its components as independent products

344) Build a product that leverages a single component for others to connect

345) Build a product that expands its way to interact with customers other than by form entry such as with voice and mobile apps

346) Build a product that improves interactivity with big fonts and smaller forms for the aged and the small screens where forms cannot be avoided

347) Build a product that leverages connectivity to keep the bulk of the processing to backends where they can scale

348) Build a product that leverages display by keeping all the frontend activities to devices and wearable.

349) Build a product that expands the same possibilities for Fortune 500

350) Build a product which becomes a Fortune 500 and gets to demand others to work with it

351) Build a product which has an easier path to growth due to its celebrity power

352) Build a product which gets accepted in industries because someone/some lobby opens doors

353) Build a product which struggles during it venture capital rounds but makes up for it with acquisition or going public

354) Build a product which has enormous appeal generated by word of mouth in academic curcles

355) Build a product with high standards where the developers revel in fewer restrictions on resources and timeline  and form a tight productive group

356) Build a product where there is proactive program management to keep the growth aligned to timelines and milestones

357) Build a product where the management deals with engineering problems in creative ways while the product is developed at the pace of the software development team

358) Build a product where the architecture team is responsible for ensuring no component is missed from the possibilities for the product and find the specifications to become obsolete before it can be revised.

359) Build a product where the growth and versioning of the product follows snowflake like pattern while the developers have to jump about from one branch to another

360) Build a product for different flavors of operating systems or cloud computing  and find the developers struggle to keep their skills up to date on each flavor.

361) Build a product and realize it has to be modified for each and every platform on which it is run.

362) Build a product and which grows significantly and then retrofit adapters to different technologies.

363) Build a product and find a number of clients requiring customizations that ends up forming an infrastructure layer facing the clients

364) Build a product that proliferates layers and components as business expands only to have them shrink and adjust afterwards.

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:

340) Build a product that builds fan following with its reliability.
341) Build a product that continuously raises the bar for the competition on Performance
342) Build a product that continuously stays in the limelight by finding one or another metric to claim to better at than the competitors.
343) Build a product that can resell part of its components as independent products
344) Build a product that leverages a single component for others to connect
345) Build a product that expands its way to interact with customers other than by form entry such as with voice and mobile apps
346) Build a product that improves interactivity with big fonts and smaller forms for the aged and the small screens where forms cannot be avoided
347) Build a product that leverages connectivity to keep the bulk of the processing to backends where they can scale
348) Build a product that leverages display by keeping all the frontend activities to devices and wearable.
349) Build a product that expands the same possibilities for Fortune 500
350) Build a product which becomes a Fortune 500 and gets to demand others to work with it
351) Build a product which has an easier path to growth due to its celebrity power
352) Build a product which gets accepted in industries because someone/some lobby opens doors
353) Build a product which struggles during it venture capital rounds but makes up for it with acquisition or going public
354) Build a product which has enormous appeal generated by word of mouth in academic curcles
355) Build a product with high standards where the developers revel in fewer restrictions on resources and timeline  and form a tight productive group
356) Build a product where there is proactive program management to keep the growth aligned to timelines and milestones
357) Build a product where the management deals with engineering problems in creative ways while the product is developed at the pace of the software development team
358) Build a product where the architecture team is responsible for ensuring no component is missed from the possibilities for the product and find the specifications to become obsolete before it can be revised.
359) Build a product where the growth and versioning of the product follows snowflake like pattern while the developers have to jump about from one branch to another
360) Build a product for different flavors of operating systems or cloud computing  and find the developers struggle to keep their skills up to date on each flavor.

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:

330) Build a product where the best laid out plans often slip the deadline.

331) Build a product where the product is written by a handful of people and maintained by hundreds.

332) Build a product where the  product builds value for other ecosystems by being the best in class

333) Build a product that adds only a minimal layer to other layers in their respective technology stack

334) Build a product where the product conforms to formats that are widely accepted making it popular over competitors

335) Build a product by looking for gaps where the competitors have not established presence or dominance yet

336) Build a product that the law enforcement agency finds easy to work with because it interacts with their systems.

337) Build a product by making in-roads into customer segments with outreach

338) Build a product where the product delights certain users by showing customizations specific to their taste

339) Build a product that makes it clear it is a commodity that can be plugged in and forgotten

340) Build a product that builds fan following with its reliability.

341) Build a product that continuously raises the bar for the competition on Performance

342) Build a product that continuously stays in the limelight by finding one or another metric to claim to better at than the competitors.
343) Build a product that can resell part of its components as independent products
344) Build a product that leverages a single component for others to connect
345) Build a product that expands its way to interact with customers other than by form entry such as with voice and mobile apps
346) Build a product that improves interactivity with big fonts and smaller forms for the aged and the small screens where forms cannot be avoided
347) Build a product that leverages connectivity to keep the bulk of the processing to backends where they can scale
348) Build a product that leverages display by keeping all the frontend activities to devices and wearable.
349) Build a product that expands the same possibilities for Fortune 500
350) Build a product which becomes a Fortune 500 and gets to demand others to work with it

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:
330) Build a product where the best laid out plans often slip the deadline.
331) Build a product where the product is written by a handful of people and maintained by hundreds.
332) Build a product where the  product builds value for other ecosystems by being the best in class
333) Build a product that adds only a minimal layer to other layers in their respective technology stack
334) Build a product where the product conforms to formats that are widely accepted making it popular over competitors
335) Build a product by looking for gaps where the competitors have not established presence or dominance yet
336) Build a product that the law enforcement agency finds easy to work with because it interacts with their systems.
337) Build a product by making in-roads into customer segments with outreach
338) Build a product where the product delights certain users by showing customizations specific to their taste
339) Build a product that makes it clear it is a commodity that can be plugged in and forgotten
340) Build a product that builds fan following with its reliability.
341) Build a product that continuously raises the bar for the competition on Performance
342) Build a product that continuously stays in the limelight by finding one or another metric to claim to better at than the competitors.

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:
320) Build a product that offers even more value in its upcoming while reducing costs.
321) Build a product that tries to play the underdog only to save the win against a competition
322) Build a product by learning from the mistakes of the leader/competitor
323) Build a product where the application is always treated to be one among a genre of applications and no matter how different the product maybe from the rest.
324) Build a product that punches the ticket in a genre of applications
325) Build a product where the awards and recognitions are given regardless of the merits of the product
326) Build a product where the approach taken is rather academic and solves some profound problems but the mainstream to go with a more mass-appeal product
327) Build a product where the effort to study the market results in a clear vision and goal for the product and reduces costs
328) Build a product where the cost of resources is not a concern but the time to market determines everything else
329) Build a product as a startup from scratch and realize that the growth of the startup shapes the software beyond the original vision
330) Build a product where the best laid out plans often slip the deadline.
331) Build a product where the product is written by a handful of people and maintained by hundreds.
332) Build a product where the  product builds value for other ecosystems by being the best in class
333) Build a product that adds only a minimal layer to other layers in their respective technology stack
334) Build a product where the product conforms to formats that are widely accepted making it popular over competitors
335) Build a product by looking for gaps where the competitors have not established presence or dominance yet
336) Build a product that the law enforcement agency finds easy to work with because it interacts with their systems.
337) Build a product by making in-roads into customer segments with outreach
338) Build a product where the product delights certain users by showing customizations specific to their taste
339) Build a product that makes it clear it is a commodity that can be plugged in and forgotten
340) Build a product that builds fan following with its reliability.

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:
310) Build a product that claims patents on features that make the competitors go to court.
311) Build a product that does not protect against modifications to its binaries and find all kinds of distributions in the marketplace.
312) Build a product that mitigates fails to protect against privacy and lose revenue from counterfeits
313) Build a product that gains popularity from illegal copies sold overseas
314) Build a product that differentiates from domestic competitors in how popular it becomes to customers in other geographic regions
315) Build a product that sustains its growth over time regardless of changes while finding it to be an uphill task.
316) Build a product with brand value that attracts people more than its revisions
317) Build a product with an attractive logo that people can find and recognize easily.
318) Build a product with a distinction in how it is perceived with respect to competitors and find the awards and recognitions become selling points.
319) Build a product that overcomes challenges in development such as technical debt, quality gates, automations and others with fewer resources and higher efficiency.
320) Build a product that offers even more value in its upcoming while reducing costs.
321) Build a product that tries to play the underdog only to save the win against a competition
322) Build a product by learning from the mistakes of the leader/competitor
323) Build a product where the application is always treated to be one among a genre of applications and no matter how different the product maybe from the rest.
324) Build a product that punches the ticket in a genre of applications
325) Build a product where the awards and recognitions are given regardless of the merits of the product
326) Build a product where the approach taken is rather academic and solves some profound problems but the mainstream to go with a more mass-appeal product
327) Build a product where the effort to study the market results in a clear vision and goal for the product and reduces costs
328) Build a product where the cost of resources is not a concern but the time to market determines everything else
329) Build a product as a startup from scratch and realize that the growth of the startup shapes the software beyond the original vision
330) Build a product where the best laid out plans often slip the deadline.

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:

300) Build a product where the product shows savings made by the end user with the use of the product and find that the product gets mentioned favorably in management reports.
301) Build a product where the components behave like products and the product is an integration of those making for an integrated basket.
302) Build a product where the advertisement to the product is stolen by the appearance and unrelated story from the celebrity
303) Build a product where the customers are left confused by the advertisement on what the product can do
304) Build a product where the customers are left confused by the advertisement on what the product cannot do
305) Build a product where the customers feel rewarded for their efforts be it the ease with which cut and paste on the screen works.
306) Build a product where the customers can change the way their search results appear so they can put it in their own presentations.
307) Build a product that does not cover liabilities with legal language protection
308) Build a product that manipulates license towards intellectual property sharing
309) Build a product that has enough patents filed that partners find it difficult to work with.
310) Build a product that claims patents on features that make the competitors go to court.
311) Build a product that does not protect against modifications to its binaries and find all kinds of distributions in the marketplace.
312) Build a product that mitigates fails to protect against privacy and lose revenue from counterfeits
313) Build a product that gains popularity from illegal copies sold overseas
314) Build a product that differentiates from domestic competitors in how popular it becomes to customers in other geographic regions
315) Build a product that sustains its growth over time regardless of changes while finding it to be an uphill task.
316) Build a product with brand value that attracts people more than its revisions
317) Build a product with an attractive logo that people can find and recognize easily.
318) Build a product with a distinction in how it is perceived with respect to competitors and find the awards and recognitions become selling points.
319) Build a product that overcomes challenges in development such as technical debt, quality gates, automations and others with fewer resources and higher efficiency.
320) Build a product that offers even more value in its upcoming while reducing costs.

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:

290) Build a product that attracts so much attention for its flaws that it becomes a baseline for the next version.
291) Build a product that is efficient in servicing and support costs and find that the product is almost forgotten
292) Build a product that empowers customers to expand  their business and find the loyalty base doubling by those who bring in others. The product may have no change in functionality and this may have resulted from the efforts of the product management and sales team only.
293) Build a product that achieves aspiring quality goals during its development and find the release to have a smaller fixed tail.
294) Build a product where the fallouts of backlog are attempted even after code freeze
295) Build a product where the quality engineering tasks that were missed out during development are attempted to be squeezed inside the final run up to release
296) Build a product where the release engineering is a concerned about quality gates only to find that the product has not embraced shift-left movement
297) Build a product where the critical bugs are discovered last
298) Build a product where the documentation is delivered in its own releases and find the costs of customer interaction reducing drastically
299) Build a product where the product reduces interaction between user and administrator and find that users are multiplying by leaps and bounds
300) Build a product where the product shows savings made by the end user with the use of the product and find that the product gets mentioned favorably in management reports.
301) Build a product where the components behave like products and the product is an integration of those making for an integrated basket.
302) Build a product where the advertisement to the product is stolen by the appearance and unrelated story from the celebrity
303) Build a product where the customers are left confused by the advertisement on what the product can do
304) Build a product where the customers are left confused by the advertisement on what the product cannot do
305) Build a product where the customers feel rewarded for their efforts be it the ease with which cut and paste on the screen works.
306) Build a product where the customers can change the way their search results appear so they can put it in their own presentations.
307) Build a product that does not cover liabilities with legal language protection
308) Build a product that manipulates license towards intellectual property sharing
309) Build a product that has enough patents filed that partners find it difficult to work with.
310) Build a product that claims patents on features that make the competitors go to court.

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:

280) Build a product where the state is stored in some form of file system or database only to find that they can be compromised in most deployments.
281) Build a product that bills incorrectly for the resources used.
282) Build a product that eavesdrops even when you are not anticipating
283) Build a product that hides sinister motives behind purported automation
284) Build a product that showcases attractive charts and graphs that never occur
285) Build a product that has fine grained automations leaving the developers delighted to build their own but at the expense of the organization.
286) Build a product that has apis for everything but they keep going through changes
287) Build a product that adds more work for the owners where the cost for the total ownership is swept under the open source tag
288) Build a product where the emphasis is on cloud friendliness but never bothers to state the assumption of being a tenant in the cloud comes with subscription cost
289) Build a product that is like an appliance sold to end-users, customers and their datacenters with little or no visibility to the business except on the budget
290) Build a product that attracts so much attention for its flaws that it becomes a baseline for the next version.
291) Build a product that is efficient in servicing and support costs and find that the product is almost forgotten
292) Build a product that empowers customers to expand  their business and find the loyalty base doubling by those who bring in others. The product may have no change in functionality and this may have resulted from the efforts of the product management and sales team only.
293) Build a product that achieves aspiring quality goals during its development and find the release to have a smaller fixed tail.
294) Build a product where the fallouts of backlog are attempted even after code freeze
295) Build a product where the quality engineering tasks that were missed out during development are attempted to be squeezed inside the final run up to release
296) Build a product where the release engineering is a concerned about quality gates only to find that the product has not embraced shift-left movement
297) Build a product where the critical bugs are discovered last
298) Build a product where the documentation is delivered in its own releases and find the costs of customer interaction reducing drastically
299) Build a product where the product reduces interaction between user and administrator and find that users are multiplying by leaps and bounds
300) Build a product where the product shows savings made by the end user with the use of the product and find that the product gets mentioned favorably in management reports.

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:
270) Build a product where the end users trust the product only to be told by hackers and researchers that it is not good enough
271) Build a product where the base line edition tantalizes the developers and the pricey edition purchase is delayed.
272) Build a product where the price of the top line spurns away some of the potential buyers
273) Build a product where the full-service solution it provides makes the customers feel like pampered.
274) Build a product where the revenue generation comes from end-user licenses sold rather than pay per use or vice versa and the company makes more money than the customers are aware
275) Build a product where the key-secrets need to be rotated but cannot be kept safe externally
276) Build a product that requires elaborate setup but find little utilization of most of the components
277) Build a product that advertises as a plug and play but doesn’t work with half the platforms
278) Build a product where the error code and error message leave the customer longing for divine intervention
279) Build a product where the mashup of technologies makes the product clunky to operate
280) Build a product where the state is stored in some form of file system or database only to find that they can be compromised in most deployments.
281) Build a product that bills incorrectly for the resources used.
282) Build a product that eavesdrops even when you are not anticipating
283) Build a product that hides sinister motives behind purported automation
284) Build a product that showcases attractive charts and graphs that never occur
285) Build a product that has fine grained automations leaving the developers delighted to build their own but at the expense of the organization.
286) Build a product that has apis for everything but they keep going through changes
287) Build a product that adds more work for the owners where the cost for the total ownership is swept under the open source tag
288) Build a product where the emphasis is on cloud friendliness but never bothers to state the assumption of being a tenant in the cloud comes with subscription cost
289) Build a product that is like an appliance sold to end-users, customers and their datacenters with little or no visibility to the business except on the budget
290) Build a product that attracts so much attention for its flaws that it becomes a baseline for the next version.

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:
260) Build a product that does not send out reminders
261) Build a product that gives all resources on lease forcing users to come back.
262) Build a product that does not release reclaim resources when the users have marked it for delete forcing them to take the steps themselves
263) Build a product that does not give the user to delete resources in bulk
264) Build a product that makes it onerous on the user to click through confirmations
265) Build a product that let’s hackers hijack user sessions
266) Build a product that is purportedly safe only to find the maker violating privacy laws
267) Build a product where the competition drives product features
268) Build a product where the release timeline is primarily motivated by competitors
269) Build a product where massive parallelizing of feature development implies human resources find their activities randomized throughout the week
270) Build a product where the end users trust the product only to be told by hackers and researchers that it is not good enough
271) Build a product where the base line edition tantalizes the developers and the pricey edition purchase is delayed.
272) Build a product where the price of the top line spurns away some of the potential buyers
273) Build a product where the full-service solution it provides makes the customers feel like pampered.
274) Build a product where the revenue generation comes from end-user licenses sold rather than pay per use or vice versa and the company makes more money than the customers are aware
275) Build a product where the key-secrets need to be rotated but cannot be kept safe externally
276) Build a product that requires elaborate setup but find little utilization of most of the components
277) Build a product that advertises as a plug and play but doesn’t work with half the platforms
278) Build a product where the error code and error message leave the customer longing for divine intervention
279) Build a product where the mashup of technologies makes the product clunky to operate
280) Build a product where the state is stored in some form of file system or database only to find that they can be compromised in most deployments.

This is a continuation of the earlier posts to enumerate funny aspects of software engineering practice:

250. Build a product that looks simple but when you click the advanced options, it becomes overwhelming.  

251. Build a product that makes you think how to query the results  

252. Build a product that gives no option to query other than scroll through the results.  

253. Build a product that makes you go and forth between pages of search results 

254. Build a product that does not let you order the results  

255. Build a product that requires you to know the jargon or the domain with little or no warning for consequences.  

256. Build a product that has clunky form to create a search criteria 

257. Build a product where the forms don’t let you see the entire entry you type 

258. Build a product where the forms don’t let you correct your mistakes  

259. Build a product that does not let you rename your resources and you have to create more  

260. Build a product that does not send out reminders  

261. Build a product that gives all resources on lease forcing users to come back.  

262. Build a product that does not release reclaim resources when the users have marked it for delete forcing them to take the steps themselves  

263. Build a product that does not give the user to delete resources in bulk 

264. Build a product that makes it onerous on the user to click through confirmations 

265. Build a product that let’s hackers hijack user sessions 

266. Build a product that is purportedly safe only to find the maker violating privacy laws 

267. Build a product where the competition drives product features 

268. Build a product where the release timeline is primarily motivated by competitors  

269. Build a product where massive parallelizing of feature development implies human resources find their activities randomized throughout the week  

270. Build a product where the end users trust the product only to be told by hackers and researchers that it is not good enough